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ADVERTISEMENT 
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REQUEST  FOR  PROPOSALS 


FOR 

THE  PROVISION  AND  OPERATION  OF  A 
PARKING  VIOLATION  /  PARKING  MANAGEMENT 
INFORMATION  SERVICES  SYSTEM  (PVPMISS) 


CITY  OF  BOSTON 

BOSTON  TRANSPORTATION  DEPARTMENT 
OFFICE  OF  THE  PARKING  CLERK  DIVISION 


DECEMBER  21,  2009 
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NOTICE  TO  PROPOSERS 


CITY  OF  BOSTON 

TRANSPORTATION  DEPARTMENT 

(OFFICE  OF  THE  PARKING  CLERK  DIVISION) 

REQUEST  FOR  PROPOSALS  FOR  THE 
PROVISION  AND  OPERATION  OF  A 
PARKING  VIOLATION/PARKING  MANAGEMENT 
INFORMATION  SERVICES  SYSTEM  (PVPMISS) 


The  City  of  Boston  (City),  acting  by  and  through  its  Transportation 
Commissioner  and  Parking  Clerk  (the  Official),  invites  proposals  for  the 
provision  and  operation  of  a  PARKING  VIOLATION/PARKING 
MANAGEMENT  INFORMATION  SERVICES  SYSTEM  (PVPMISS).  The 
PVPMISS  is  a  large  volume,  highly  complex  computer-based  operation  which 
integrates  and  supports  numerous  elements  relative  to  the  processing  and 
adjudication  of  parking  violation  tickets.  The  provision  and  operation  of  a 
PVPMISS  will  require  a  single-point-of-responsibility  for  such  services  and  is 
fully  described  in  the  Request  for  Proposals  documents  (RFP  documents)  that 
will  be  available  at  the  Boston  Transportation  Department/Office  of  the 
Parking  Clerk,  Room  224,  City  Hall,  Boston,  Massachusetts  02201,  from  on 
or  after  Monday,  December  21,  2009,  to  Wednesday,  January  27,  2010.  A 
charge  of  twenty-five  dollars  ($25)  payable  by  check  or  money  order  to  the 
City  of  Boston  shall  be  required  to  cover  the  cost  of  the  RFP  documents. 

A  proposers'  conference  will  be  held  on  Wednesday,  January  27,  2010 
at  10:00  A.M.,  Boston  time,  in  Room  900  (the  Boston  Redevelopment 
Authority  Board  Room)  Boston  City  Hall,  9th  Floor.  ATTENDANCE  AT 
THE  PROPOSERS'  CONFERENCE  IS  MANDATORY.  Failure  of  a 
proposer  to  appear  at  the  proposers'  conference  will  disqualify  the  proposer 
from  submitting  a  proposal. 

All  proposals  shall  be  submitted  in  strict  conformance  with  the 
instructions  contained  in  the  RFP  documents.  The  response  to  this  Request 
for  Proposals  shall  consist  of  the  original  signed  and  five  (5)  copies  of  the 
technical  (non-price)  proposal,  the  original  separate  and  sealed  price  proposal, 
and  one  sealed  copy  of  the  price  proposal,  and  shall  be  delivered  no  later  than 
Wednesday,  February  17,  2010,  at  12  o'clock  noon  (Boston  time)  to  the 
Boston  Transportation  Department/Office  of  the  Parking  Clerk,  Room  224, 
City  Hall,  Boston,  Massachusetts  02201. 

FAILURE  TO  SUBMIT  SEPARATE  SEALED  PRICE  AND  NON- 
PRICE  PROPOSALS  SHALL  RESULT  IN  DISQUALIFICATION  OF  THE 
ENTIRE  PROPOSAL. 
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A  proposal  deposit  in  the  form  of  a  certified  check  drawn  on,  or  a 
treasurer's  or  cashier's  check  issued  by,  a  responsible  bank  or  trust  company 
and  made  payable  to  the  City  of  Boston,  or  a  proposal  bond  issued  by  a  surety 
company  authorized  to  do  business  in  the  Commonwealth  of  Massachusetts 
and  satisfactory  to  the  Official  shall  be  submitted  with  the  original  technical 
(non-price)  proposal.  The  amount  of  such  check  or  the  penal  sum  of  such 
bond  shall  be  in  the  sum  of  twenty-five  thousand  dollars  ($25,000). 

To  guarantee  the  faithful  performance  of  any  contract  entered  into 
pursuant  to  the  RFP,  the  successful  proposer  will  be  required  to  provide  a 
performance  bond  in  the  sum  of  one  million  dollars  ($1,000,000)  from  a 
surety  company  authorized  to  do  business  in  the  Commonwealth  of 
Massachusetts  and  satisfactory  to  the  Official. 

The  award  of  a  contract  under  this  Request  for  Proposals  shall  be  based 
upon  a  determination  of  the  most  advantageous  proposal  from  a  responsible 
and  responsive  offeror  taking  into  consideration  price  and  the  evaluation 
criteria  set  forth  in  the  proposal  documents. 

The  Request  for  Proposals  shall  be  for  a  maximum  term  of  three  (3) 
years,  as  follows:  an  initial  term  of  twelve  (12)  months,  commencing  July  1, 
2010,  and  ending  June  30,  2011,  with  options  on  the  part  of  the  Official  to 
renew  for  two  (2)  successive  twelve  (12)  month  periods  ending  on  June  30, 
2013. 

The  initial  award  and  subsequent  renewal  of  any  contract  shall  be 
subject  to  the  approval  of  the  Mayor  of  Boston. 

The  City  reserves  the  right  to  accept  or  reject  any  or  all  proposals  or  any 
part  or  parts  thereof;  to  waive  any  defects,  informalities  and  minor 
irregularities;  and  to  award  the  contract  as  the  City  deems  to  be  in  its  best 
interest.  The  maximum  time  for  proposal  acceptance  by  the  City  is  ninety 
(90)  days  after  the  above-mentioned  date  specified  for  receipt  of  proposals. 


City  of  Boston 
Transportation  Department 
Office  of  the  Parking  Clerk  Division 
Thomas  J.  Tinlin 
Commissioner/Parking  Clerk, 
Room  224 
Boston  City  Hall 
Boston,  MA  02201 
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SECTION  1.0 


PURPOSE  AND  OBJECTIVES  OF  THE  REQUEST 
FOR  PROPOSALS  fRFP) 


The  City  of  Boston  Transportation  Department  (BTD)  has  instituted  a 
comprehensive  and  integrated  approach  to  transportation  and  parking 
management.  The  purpose  of  this  Request  For  Proposals  is  to  obtain 
submittals  from  qualified  proposers  for  the  provision  and  operation,  in 
accordance  with  the  City's  specifications  and  requirements,  of  an  automated 
Parking  Violation/Parking  Management  Information  Services  System 
(PVPMISS)  and  the  provision  of  on-going  services. 

It  is  the  intent  of  the  City  of  Boston  to  have  various  functions  and  activities 
associated  with  parking  violation  ticket  record-keeping,  processing, 
adjudication,  collection  and  non-response  (causing  a  ticket  collection  activity), 
and  related  parking  enforcement  and  management  functions  and  activities, 
extensively  integrated  into  a  unified,  sophisticated,  comprehensive,  highly 
functional,  user-oriented,  turnkey  system  that  will  operate  in  a 
production  environment  on  July  1,  2010.  The  provision  of  a  proven, 
established,  successful,  efficient,  effective,  and  comprehensive  PVPMISS  is 
critical  to  the  City's  ability  to  fulfill  its  transportation  and  parking 
management  objectives. 

The  PVPMISS  proposed  must  fully  support  numerous  functions  and  activities 
which  are  set  forth  in  this  RFP  and  generally  include:  parking  violation  ticket 
processing,  registrant  data  acquisition,  public  inquiry  response  and  processing, 
adjudication,  collections,  numerous  related  transportation  and  on-street 
parking  management  activities,  accounting/financial  processing  and  record- 
keeping requirements  associated  with  an  operation  of  this  complexity  and 
size,  audit  trails,  edits  and  controls  on  all  activities  and  transactions, 
management  reporting,  and  management  services.  This  PVPMISS  must  also 
be  able  to  fully  support  improvements  and  expansions  in  these  areas. 

The  PVPMISS  must  have  a  high  degree  of  flexibility  to  accommodate  major 
system  modifications  and  enhancements,  in  particular,  the  addition  of  new 
data  elements,  new  on-line  inquiry  capabilities,  and  new  on-line  and  batch 
processing  capabilities. 

The  selected  PVPMISS  proposer  must  be  able  to  provide  technical  assistance  and  the 
necessary  resources  to  expand  and  enhance  existing  systems  and  operations  and 
develop  and  implement  new  activities  and  programs. 

The  effective  and  efficient  management  and  operation  of  the  BTD  is  essential  to  the 
City  and  directly  impacts  the  quality  of  life  in  Boston.  A  cornerstone  to  the  fulfillment 
of  many  of  the  BTD's  parking  management  responsibilities,  which  includes  the 
maximization  of  responsiveness  to  the  public  and  various  traffic  and  parking 
constituents,  is  a  highly  efficient  and  effective  PVPMISS  with  optimal  functionality  and 
utility.  The  PVPMISS  has  a  direct  and  significant  impact  on  the  efficiency, 
effectiveness  and  capabilities  of  the  public  inquiry,  information  processing,  adjudication 
and  enforcement/collection  efforts  of  the  City  as  they  relate  to  parking  enforcement  and 
management. 
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Further,  proposers'  capabilities  relative  to  obtaining,  processing  and  using  data  and 
information  (particularly  registrant  data  and  information)  will  have  a  significant  impact 
on  revenues  and  costs  and  could  have  a  negative  effect  on  the  integrity  of  the  City's 
PVPMISS.  The  lack  of  data,  the  application  of  incorrect  data,  the  ineffective  or 
inefficient  processing  of  data,  the  inability  to  thoroughly  validate  data  or  the  lack  of 
adequate  quality  control  to  detect  problems,  all  serve  to  adversely  impact 
enforcement/collections  and  in  many  cases  increase  the  costs  related  to  handling  and 
adjudicating  inquiries  and  disputes. 

An  important  objective  of  the  City  is  to  deter  illegal  parking  via  the  collection  of 
parking  violation  and  related  parking  management  fines,  penalties  and  other  charges 
that  are  legitimately  due  the  City.  The  amount  of  PVPMISS  related  funds  which 
eventually  are  netted  by  the  City  will  be  determined  in  large  part  by:  a)  the  efficiency 
and  effectiveness  of  the  PVPMISS  Vendor's  data  processing  operations  relative  to 
enforcement/collection  efforts;  b)  the  cost  of  the  PVPMISS  Vendor's  services  in  actual 
charges;  and  c)  the  costs  for  operations,  adjudication,  oversight,  etc.,  in  terms  such  as 
staffing  requirements  to  maintain  service  levels. 

A  comprehensive  and  complete  PVPMISS  is  expected  to  provide  extremely  high  levels 
of  data  accuracy  and  integrity;  to  maintain  extremely  high  levels  of  system  and 
operational  efficiency,  effectiveness  and  integrity;  and  to  maximize  the  availability  of, 
and  the  effective  and  correct  processing  and  use  of  data  for  the  purposes  of  public 
inquiry,  dispute  resolution  and  adjudication,  and  collections.  Proposers  should  not 
underestimate  the  importance  of  customer  service  capabilities  of  the  PVPMISS. 

A  proposer's  ability  to  fully  demonstrate  and  substantiate  that  it  can  provide  a  proven 
and  established  turnkey  PVPMISS  —  and  its  ability  to  demonstrate  and  substantiate 
successful  past  performance  with  results  comparable  to  Boston's  existing 
performance  levels  in  PVPMISS  installations  that  are  similar  and  comparable  to 
Boston's  PVPMISS  and  with  systems  and  services  that  are  similar  and  comparable 
to  those  required  in  this  RFP  —  is  of  major  importance  to  the  City. 

Essentially,  the  PVPMISS  must  deliver  an  extremely  high  level  of  quality  systems  and 
services.  The  PVPMISS,  as  noted,  is  an  important  and  integral  part  of  the  City's  total 
transportation  and  parking  management  program. 

The  City  currently  utilizes  the  services  of  an  outside  vendor  under  contract  for  the  major 
portion  of  its  PVPMISS  data  processing  requirements.  Through  the  contract  that  is 
awarded  pursuant  to  this  RFP,  the  City  seeks  to  expand  the  capabilities  of  the  existing 
parking  ticket/parking  management  processing  and  information  system. 

The  contract  that  is  to  be  awarded  pursuant  to  this  RFP  will  be  for  a  maximum  term  of 
three  (3)  years,  as  follows:  an  initial  term  of  twelve  months,  commencing  on  July  1, 
2010,  and  ending  on  June  30,  2011,  with  options  on  the  part  of  the  City  to  renew  at  the 
end  of  each  fiscal  year,  for  a  maximum  of  two  (2)  additional  (and  consecutive)  twelve 
month  periods  ending  on  June  30,  2013.  The  contract  awarded  pursuant  to  this  RFP 
shall  be  subject  to:  the  approval  of  the  Mayor  of  Boston  in  each  fiscal  year,  the 
availability  of  an  appropriation  in  each  fiscal  year,  and  the  reasonable  investigation  of 
costs  and  benefits  for  each  fiscal  year  so  as  to  determine  that  the  exercise  of  any  option 
to  renew  is  more  advantageous  than  alternative  means  of  procuring  these  PVPMISS 
services. 
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Responses  to  this  RFP  must  be  prepared  exactly  in  accordance  with  the  requirements 
contained  therein.  Evaluation  of  the  responses  will  be  made  by  the  Parking  Clerk 
and/or  his  designee(s). 

Selection  of  a  Vendor  (i.e.,  Contractor)  will  be  based  upon  an  evaluation  and  analysis  of 
the  information  and  other  materials  presented  as  required  under  the  RFP.  Additionally, 
the  City  may  require  presentations,  demonstrations  and/or  conduct  reviews  of  other 
operational  sites  and  references. 

Evaluation  criteria  which  will  be  utilized  by  the  City  to  determine  the  most 
advantageous  proposal  are  set  forth  in  this  RFP. 
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SECTION  2.0 


BACKGROUND  AND  OVERVIEW  OF  THE  BTD  AND  PVPMISS 


(2.1)  Brief  Historical  Note 

During  the  1970's  and  early  1980's  the  issuance  of  parking  violations,  due  to  inadequate  and 
ineffective  enforcement/collection  methods  and  efforts,  was  not  a  meaningful  instrument  in 
improving  public  safety,  enhancing  traffic  flow,  increasing  the  availability  of  on-street  parking 
spaces,  and  generally  deterring  illegal  parking.  Moreover,  the  data  processing  system  was 
extremely  inadequate  in  terms  of  supporting  the  public  responsiveness  needs  of  a  parking 
violation  processing  system. 

In  January  1982,  the  City  assumed  exclusive  responsibility  for  the  parking  violation  system. 
Since  then,  continuous,  significant  enhancements  and  modifications  have  been  made  to  parking 
violation  related  systems  and  operations. 


(2.2)  Overview  and  Importance  of  the  BTD  and  PVPMISS 

The  Boston  Transportation  Department  (BTD)  is  responsible  for  the  planning  and  management 
of  short-term  and  long-term  traffic  and  parking  needs  within  the  City  of  Boston.  As  part  of 
these  responsibilities,  the  BTD  is  responsible  for  the  oversight,  administration,  utilization  and 
(where  applicable)  operation  of  the  City  of  Boston's  Parking  Violation/  Parking  Management 
Information  Services  System  (PVPMISS).  The  Office  of  the  Parking  Clerk  (BTD/OPC) 
division  of  the  BTD  serves  as  the  primary  agent  for  the  department  in  this  regard,  as  well  as  for 
the  issuance  and  evaluation  of  this  RFP. 

The  scope  and  magnitude  of  the  BTD's  areas  of  responsibility  are  considerable.  The  functions 
of  the  BTD's  various  divisions  as  they  relate  to  this  RFP  are  summarized  on  the  following 
pages. 

The  demand  for  BTD  services  from  resident,  commercial  and  other  constituents  is  extremely 
high.  The  BTD's  mission  to  maintain  and  enhance  the  quality  of  life  in  Boston  is  exemplified 
by  the  following  sample  of  facts  and  duties: 


As  a  'basic  service  department'  the  BTD  monitors  and  regulates  traffic  and  parking 
uses  for  roadways  and  streets.  The  regulation  and  management  duties  of  these 
roadways  are  numerous  and  vital  and  encompass  public  safety  issues,  traffic  signals 
and  signs,  intersection  flow,  crosswalks,  construction  management  and  many  other 
duties. 
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*  The  City  faces  many  transportation  policy,  planning  and  construction  issues,  such  as 
the  Third  Harbor  Crossing  (Tunnel)  and  the  depression  of  the  Central  Artery. 

*  A  federally  mandated  Parking  Freeze  constrains  the  City  with  a  parking  space 
capacity-to-demand  ratio  of  approximately  1:3. 

The  above,  and  many  other  compelling  facts  and  responsibilities,  clearly  demonstrates  that  the 
effective  and  efficient  management  and  operation  of  the  BTD  is  essential  to  the  City  and 
directly  impacts  the  quality  of  life  in  Boston.  The  provision  and  operation  of  an  efficient  and 
effective  PVPMISS  contributes  greatly  towards  this  goal. 

Over  the  past  decade,  the  Parking  Violations  System  (PVS)  has  evolved  into  the  more 
comprehensive  PVPMISS  and  has  been  fully  integrated  into  the  City's  transportation  and 
parking  management  program.  This  system  includes  the  primary  parking  violation  processing 
system,  correspondence  imaging  system,  subsystems  and  elements  as  well  as  important  related 
parking  management  components  such  as  the  Meter  Management  System  and  the  On-Line 
Claims  Processing  System. 

It  is  very  important  for  proposers  to  understand  that  the  City-wide  goals  of  the  PVPMISS 
include  improved  traffic  flow,  public  safety,  and  increasing  the  availability  of  on-street  parking 
spaces  in  a  manner  consistent  with  transportation  and  parking  management  objectives.  It  is 
also  important  that  the  proposers  recognize  that  responsiveness  to  the  public  is  a  primary  goal. 

The  current  Parking  Violation  Parking  Management  Information  Services  System  (PVPMISS) 
is  a  large  volume;  highly  complex  advanced  computer-based  operation  involving  a  major  data 
processing  system  and  numerous  manual  and  automated  subsystems,  elements  and  functions. 
The  operation  involves  numerous  interfaces  and  coordination  among  and  between  internal  and 
external  entities.  The  processing,  adjudication,  collection  and  final  disposition  of  parking 
violations  is  inherently  complex.  The  data  environment  is  also  complex  and  the  events  are 
numerous  and  permutational. 

The  PVPMISS  integrates  and  supports  every  facet  of  parking  ticket  and  related  parking 
management  elements  from  ticket  procurement  through  ticket  and  related  activity  processing  to 
final  disposition.  Essentially,  the  PVPMISS  is  characterized  by  its  hybrid  nature  and 
singularity  in  relation  to  other  automated  record-keeping/transaction  systems. 

Approximately  1.6  to  1.7  million  tickets  are  issued  within  the  City  on  an  annual  basis. 
Approximately  60  million  dollars  annually  are  collected  from  all  PVPMISS  sources  (i.e.  ticket 
payments,  boot  and  tow  charges,  violation  tow  fees,  storage  fees,  lease/  rental/taxi  surcharge 
payments,  abandoned  vehicle  payments,  and  dishonored  [bounced]  check  fees).  Roughly 
twenty  percent  of  the  parking  ticket  collections  are  derived  from  tickets  issued  prior  to  the 
current  fiscal  year.  As  of  June  1,  2009,  there  were  approximately  2  million  tickets  on  the 
current  PVPMISS  on-line  system. 
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(2.3)  Enforcement/Collection  Remedies 


The  City  utilizes  a  number  of  enforcement/collection  remedies  to  attain  compliance  with  its 
Traffic  and  Parking  Rules  and  Regulations.  It  should  be  noted  that  the  success  of  these 
enforcement/collection  remedies  are  to  a  very  large  extent  dependent  upon  our  ability  to  obtain 
and  be  able  to  effectively  process  accurate  and  timely  registrant  data  from  the  Massachusetts 
Registry  of  Motor  Vehicles. 


1.    The  Parking  Ticket: 

Parking  tickets  are  affixed  to  vehicles  parked  illegally  on  City  of  Boston  streets. 
The  actual  parking  ticket  reflects  the  specific  violation  and  the  corresponding  fine 
amount  (fine  amounts  range  from  $15.00  to  $120.00).  The  parking  tickets  are 
issued  by  approximately  sixteen  (16)  different  agencies.  Parking  ticket  data, 
information  and  transactions  are  updated  and  maintained  on  the  PVPMISS.  The 
accurate  and  timely  processing  of  the  parking  tickets  and  related  transactions  and 
activities  is  a  critical  and  essential  element  of  the  PVPMISS. 


2.    Delinquency  Notices: 

A  variety  of  standard  notices  are  mailed  to  both  Massachusetts  and  Out-of-State 
registrants.  Specific  criteria  are  developed  for  each  of  the  notices.  The  City's  data 
processing  vendor  generates  these  notices.  The  delinquency  notices  reflect  the 
original  fine  amount,  late  penalties  of  $5.00  to  $40.00  (depending  on  the  violation) 
that  have  been  assessed  due  to  non-payment  of  the  fine  amount  within  twenty-three 
(23)  days,  and  non-renewal  penalties  of  $20.00  per  ticket.  All  information  relating 
to  these  notices  is  recorded  and  reflected  in  the  PVPMISS.  This  program  is  a  major 
component  of  the  PVPMISS.  Moreover,  it  should  be  noted  and  recognized  that  the 
success  of  this  program  is  very  dependent  upon  the  selected  proposer's  capability  to 
obtain  accurate,  timely,  and  usable  registrant  data  from  the  Massachusetts  Registry 
of  Motor  Vehicles  and  the  motor  vehicle  bureaus  of  other  states. 


3.    Seizure/Booting  and  Towing: 

The  vehicles  of  violators  who  have  five  (5)  or  more  outstanding  tickets  are  eligible 
for  seizure/booting  and  towing.  Once  a  vehicle  is  seized  under  this  program,  a 
registrant  is  responsible  for  paying  all  outstanding  tickets,  a  $56.00  seizure  fee,  and 
a  $3.00  per  hour  (to  a  maximum  of  $15.00  per  day)  storage  fee.  This  program  is  a 
major  component  of  the  PVPMISS. 
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4.    Non-Renewal  of  Driver's  License  and  Registration: 


Tickets  that  are  more  than  105  days  old  and  still  remain  unpaid  are  sent  to  the 
Registry  of  Motor  Vehicles  for  non-renewal  of  the  registered  owner's  driver's 
license  and  registration.  A  $20.00  per  ticket  surcharge  is  assessed.  The  surcharge 
is  collected  by  the  City  but  deducted  from  the  City's  state  aid  funds  by  the  State 
Treasurer.  Accurate,  effective,  and  timely  processing  of  parking  ticket  data  and 
information  to  the  Massachusetts  Registry  of  Motor  Vehicles  is  critical  to  this 
program's  success.  This  program  is  a  major  component  of  the  PVPMISS. 


5.    Special  Collections: 

Certain  groups  of  violators  or  populations  of  tickets  are  targeted  for  unique 
collection  activities. 


A.   Lease.  Rental  and  Taxi  Vehicles: 

1.  Lessee  Identification  and  Noticing  Program: 

The  City  designed  its  own  unique  noticing  system  specifically  oriented  to 
rental  and  leasing  companies  and  the  actual  renter/lessee.  The  system 
operates  on  the  Vendor's  mainframe.  All  payments  received  through  this 
program  are  processed  through  the  PVPMISS.  The  PVPMISS  must  be 
able  to  accommodate  this  important  program. 

2.  Rental.  Lease,  and  Taxi  Vehicle  Surcharge: 

The  City  receives  a  $.60  surcharge  per  each  rental,  lease  and  taxi  vehicle 
contract  transaction  that  occurs  in  the  City  of  Boston.  The  surcharge 
amount  may  increase.  All  payments  are  directly  processed  through  an  on- 
line PVPMISS  terminal  as  part  of  the  Fleet  Vehicle  System  and  are 
tracked  separately  in  the  PVPMISS.  This  is  a  major  program  of  the 
PVPMISS. 


B.   Fleet  (Multi  Owner)  Vehicle: 

The  City  utilizes  a  specialized  vendor-provided  system  and  program  for 
companies  with  both  small  and  large  fleets  of  vehicles.  A  considerable  number 
of  companies  have  agreed  to  participate  in  the  program  and  pay  their 
outstanding  tickets  on  a  monthly  basis.  The  City  receives  computer  tapes 
and/or  reports  from  the  PVPMISS  vendor  and  distributes  these  to  the 
participating  companies.  This  is  a  major  program  of  the  PVPMISS. 
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C.    Seizure  Identification  System  File: 


The  City  has  established  a  program  to  target  certain  groups  of  scofflaws  and 
populations  of  delinquent  tickets.  The  PVPMISS  vendor  provides  the  Office 
of  the  Parking  Clerk  with  most  of  the  names  and  addresses  of  out-of-state 
registrants  whose  vehicles  will  appear  in  the  City's  Boot  Eligible  File  /  Book. 
In  some  cases  the  BTD/OPC  will  send  letters  generated  from  a  word 
processing  system  to  the  out-of-state  Registry  of  Motor  Vehicles  who  in  return 
provide  the  BTD/OPC  with  the  names  and  addresses  of  the  registrants.  Once 
the  name  and  address  is  obtained,  the  Vendor's  mainframe  computer  will 
generate  a  letter  style  notice  to  the  individual  responsible  for  the  vehicle. 


D.   Resident  Parking  Permit  Releases: 

The  City  has  instituted  Resident  Permit  Parking  Programs  in  a  number  of 
neighborhoods.  Residents  are  able  to  obtain  a  parking  permit  at  no  cost. 
However,  the  residents  are  required  to  pay  or  dispute  outstanding  parking 
tickets  before  being  issued  a  parking  permit.  The  City  utilizes  a  vendor- 
provided  system  for  the  administration  of  this  program  including  the  issuance 
of  new  and  renewed  permits. 


6.    Backlog  Collections: 

The  City  has  in  the  past  turned  over  old  tickets  for  secondary  collection  to  the 
PVPMISS  vendor.  The  PVPMISS  vendor  currently  does  not  receive  any  fee  if  the 
payment  made  on  a  ticket  is  the  result  of  a  boot  or  tow  seizure  or  the  ticket  is  in 
non-renewal  status  in  accordance  with  the  City's  Backlog  Collections  criteria.  An 
important  feature  of  the  PVPMISS  is  a  ticket  payment  tracking  and  billing  system 
to  identify  the  cause  of  each  ticket  payment  in  the  backlog  population. 


7.    Violation  Tow  Program: 

The  City,  in  an  effort  to  improve  traffic  flow  and  achieve  critical  parking 
management  objectives,  tows  vehicles  that  are  in  violation  of  certain  regulations 
(e.g.,  No  Stopping  and  Standing).  The  registrants  of  vehicles  that  have  been  towed 
are  required  to  pay  a  $90.00  violation  tow  fee  and  a  $3.00  per  hour  (to  a  maximum 
of  $15.00  per  day)  storage  charge.  As  the  result  of  recently  enacted  or  pending 
legislation,  the  violation  tow  fee  and  storage  charge  amounts  may  increase.  This 
violation  tow  element  is  an  important  feature  of  the  PVPMISS. 
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8. 


Abandoned  Vehicle  Program: 


The  Abandoned  Vehicle  Program  helps  reduce  the  number  of  vehicles  left  on  City 
streets  to  be  disposed  of  at  the  City's  expense.  The  legislation  that  helped  create 
this  program  imposes  a  fine  of  $250-$500  for  abandoning  a  vehicle.  The  Office  of 
the  Parking  Clerk  is  responsible  for  collecting  the  fines  and  conducting  the 
associated  adjudication  procedures.  Since  the  law's  inception,  the  BTD/OPC  has 
sent  notices,  via  the  Vendor,  to  the  owners  of  cars  that  have  been  abandoned  and 
towed.  Revenue  collected  for  Fiscal  Year  2009  was  approximately  $245,132. 


9.    Auctioned  Vehicles: 

On  a  routine  basis  the  Boston  Police  Department  auctions  unclaimed  vehicles  from 
the  City's  Tow  Lot.  (The  funds  are  deposited  by  the  Police  Department  into  a  City 
account  and  thus  are  not  reflected  in  the  Parking  Violations  System  account.) 


(2.4)  Inquiries  and  Disputes: 

The  BTD/OPC  receives  phone,  walk-in,  and  mail  inquiries  or  disputes  concerning  more  than 
ten  (10)  percent  of  the  tickets  issued  during  a  year.  A  comprehensive  information  system  is 
utilized  in  conjunction  with  a  comprehensive  administrative  review  process  and  hearings  to 
respond  to  inquires  and  resolve  disputes.  The  comprehensiveness,  the  accuracy  and  the 
integrity  of  the  data  and  information  in  the  PVPMISS  in  combination  with  the  ability  and  ease 
of  staff  to  access  and  use  the  data  and  information  has  a  direct  bearing  on  the  City's  ability  to 
utilize  enforcement  and  collection  programs  to  achieve  compliance  with  its  traffic  and  parking 
regulations  and  attain  its  transportation  goals. 

The  PVPMISS  plays  an  important  role  relative  to  the  BTD/OPC's  ability  to  adequately  and 
appropriately  respond  to  and  resolve  public  inquiries  and  disputes.  The  BTD/OPC  has  insisted 
and  will  continue  to  insist  that  more  elements  and  features  be  provided  that  will  enhance  and 
expand  the  current  level  of  responsiveness.  The  selected  PVPMISS  proposer  is  expected  to 
fully  provide  the  technical  assistance,  systems  development  capability  and  the  necessary 
resources  to  enable  BTD/OPC  to  carry  out  its  important  public  inquiry  and  adjudication 
mission. 

Examples  of  public  inquiry  activity  for  Fiscal  Year  2009  are  provided  below: 


o 


o 


o 


o 


o 


Counter  Activity  22,139 

Phone  Activity  419,016 

Correspondence  Received   90,348 

Hearings  Held  13,036 

Resident  Parking  Walk-in  Inquiries..  35,978 


20 


(2.5)  Major  Organizations  Involved  in  Current  Operations: 

A  brief  description  of  the  activities  of  BTD/OPC  units  and  other  organizations  relative  to  the 
PVPMISS  is  provided  below: 


(2.5.1)  OPC  Division  Organizational  Units 

1.    Public  Inquiry  Unit: 

This  OPC  unit  primarily  reviews,  researches  and  classifies  requests  related  to  ticket 
disputes,  completes  the  necessary  forms  and  transactions  and  data  enters  the 
information.  The  data  entry  component  of  this  unit  also  performs  the  data  entry 
tasks  for  the  review,  research  and  classification  work  done  by  walk-in  and  phone 
bank  staff. 


A.  Correspondence: 

The  Correspondence  staff  performs  the  scheduling  of  hearings,  the  disposition 
of  the  hearings  and  the  updating  of  previous  requests.  This  unit  is  involved  in 
the  research,  documentation  and  preparation  of  refund  requests  as  well  as  a 
filing  system  for  all  refund  forms  and  answering  questions  related  to  refund 
inquiries.  On-Line  access  of  third  party  databases  are  used  by  this  unit  for 
research  and  verification  purposes  and  are  also  utilized  by  all  other  OPC  units. 
The  databases  include:  the  meter  management  system,  the  resident  permit 
database  and  the  MA  Registry  of  Motor  Vehicles  (UMS).  This  unit  also 
maintains  a  record  keeping  system  that  allows  all  OPC  staff  to  track  and  locate 
important  source  documents  filed  both  in-office  (microfiche,  microfilm)  and 
off-site. 


B.   Telephone  and  Walk-In  Inquiries: 

This  unit  is  essentially  involved  in  the  resolution  of  walk-in  and  phone 
inquiries.  Walk-in  claims  involve  reviewing  and  classifying  the  ticket  request 
and  completing  the  appropriate  form  for  data  entry.  Also  included  in  these 
walk- in  claims  are  special  requests/problems  such  as:  walk-in  hearings, 
resident  sticker  clearances,  administrative  boot  releases,  non-renewal 
clearances,  etc.  Phone  inquiries  involve  answering  questions  concerning 
tickets,  booting,  towing,  office  policies  and  procedures,  state  law,  etc.,  and 
advising  the  caller  of  the  course  of  action  to  take  to  resolve  the  dispute  and 
often  mailing  out  information  to  callers.  This  also  includes  responding  to  and 
researching  inquiries  and  disputes  involving  non-renewal  action  and  provides 
renewal  releases. 
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C.   Resident  Parking  Permit  Issuance: 


This  unit  issues  and  renews  resident  parking  permits  according  to  established 
BTD/OPC  policies  and  procedures.  This  includes  requirements  pertaining  to 
automobile  registrations,  proof  of  residency  and  overdue  parking  violations  . 
This  staff  is  involved  in  the  research  and  resolution  of  constituent  disputes 
relative  to  the  issuance  of  resident  parking  permits.  This  unit  must  maintain 
records  of  permits  for  OPC  staff  research.  The  on-line  record  keeping  system 
for  RPP  data  is  maintained  in  conjunction  with  the  vendor's  PVPMISS  for 
over  220,000  resident  permit  records.  This  includes  periodic  system 
reorganization,  purges  and  transfer  of  records  to  an  audit  file.  The  Resident 
Parking  Permit  Unit  also  generates  renewal  notices  to  all  valid  permit  holders 
on  a  monthly  basis,  which  allows  recipients  to  renew  through  the  mail  or  in- 
person.  Once  the  applications  are  received  it  is  necessary  for  the  staff  to 
review,  make  a  disposition  and  classify  all  applications.  Periodically  an  audit 
is  conducted  with  the  RMV  of  all  valid  permit  holders.  This  procedure  serves 
as  a  security  measure  to  ensure  that  all  vehicles  issued  permits  are  registered  in 
the  City  of  Boston. 


2.    Lease/Taxi  and  Fleet  Collections  and  Cashiering: 

A.   Lease/Taxi  and  Fleet  Collections: 

This  unit  is  involved  in  the  operation  and  oversight  of  the  Lease/Taxi 
Vehicle  and  Fleet  Vehicle  System.  The  operation  of  the  Lease  Vehicle 
Program  involves  lessee/lessor  identification  and  correspondence,  which 
includes  reviewing  correspondence  received  daily;  recording  name/address 
(lessee)  information;  completing  appropriate  forms  for  data  entry  through  the 
Lease  Vehicle  System.  The  Fleet  Program  sends  a  monthly  report  of 
outstanding  violations  issued  to  participating  companies,  thereby  alleviating 
the  need  to  send  parking  ticket  notices.  A  unit  liaison  is  involved  in  answering 
questions  from  lessees,  leasing  and  taxi  companies  and  fleets  concerning  ticket 
disputes,  the  law  governing  lease  vehicles,  registry  releases,  hackney  renewals 
and  booted  vehicles.  Additional  functions  include  data  entry  of  lease/fleet 
information  and  the  scheduling  of  lessee  hearings;  lessee  payment  tracking; 
on-line  cashiering  which  includes  the  processing  of  checks  received  at  the  OPC 
office  primarily  from  fleet  and  lease/rental  companies;  and  serves  as  liaison  to 
Freedom  Trail  payment  services.  This  units  responsibilities  also  include  the 
processing  of  general  correspondence,  correspondence  involving  non-renewal 
and  resident  parking  requests,  boot  and  non-renewal  payments;  and  the 
payment  processing  and  tracking  of  lease/rental/taxi  surcharge  transaction. 
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B.  Cashiering: 


The  Cashiering  Unit  collects  parking  ticket,  boot  and  tow,  abandoned  vehicle  and 
storage  payments.  The  cashiers  operate  three  (3)  of  the  real  time  on-line  cashiering 
workstations.  They  also  issue  Registry  Release  forms  and  transmit  boot  and  tow 
releases  electronically  through  the  on-line  cashiering  workstations.  Payments 
entered  into  this  system  are  reflected  immediately  on  the  PVPMISS  on-line 
computer  system  utilized  by  OPC.  This  unit  is  also  responsible  for  balancing  Daily 
Summary  totals  as  well  as,  cash,  checks,  credit  card  and  debit  card  payments  for 
OPC  and  the  Tow  Lot  to  be  submitted  to  the  Treasury  for  deposit.  The  methods  of 
payment  accepted  are:  cash,  credit  card  (VISA,  MASTERCARD)  debit  card, 
personal  check  and  money  order.  We  may  also  require  the  ability  to  accept 
payment  by  American  Express  and  Discover  credit  cards. 


3.    Hearings  and  Adjudication: 

This  unit  schedules  and  conducts  hearings  for  the  adjudication  of  disputed  parking 
tickets  and  abandoned  vehicle  tickets.  This  involves  the  coordinating  of  hearing 
officers  with  individuals  waiting  to  have  walk-in  or  pre-scheduled  hearings; 
insuring  that  hearings  are  conducted  efficiently  and  fairly;  and  answering  questions 
concerning  hearing  procedures.  Other  duties  involve  the  development  of  an 
automatic  hearing  schedule  plan  based  on  appearance  rate  for  different  types  of 
requests  and  different  populations  of  registrants;  the  preparation  of  hearing  rooms 
and  computer  based  record  keeping  systems;  the  preparation  of  dispositions, 
documents  and  transcripts  for  representation  of  the  City  for  appeals  in  Superior 
Court.  The  maintenance  of  hearing  manuals  and  the  law  library  is  a  responsibility 
of  this  unit,  which  provides  Hearing  Officers  with  information  on  applicable 
policies,  practices,  procedures,  ordinances,  regulations  and  statutes  relating  to 
hearing  issues.  Adjudication  records  are  maintained  by  this  unit,  which  involves 
the  overseeing  of  a  record-keeping  system  that  allows  all  OPC  staff  to  track  and 
locate  important  hearing  documents. 


4.    Quality  Assurance  Systems  Development  and  Contract  Administration: 

This  unit  is  primarily  involved  in  the  development  and  design  of  all  PVPMISS 
related  activity  and  serves  as  the  primary  liaison  to  the  vendor.  This  includes 
oversight  and  approval  of  all  vendor  PVPMISS  design  efforts.  This  unit  monitors 
system  and  vendor  performance  via  a  comprehensive  quality  assurance  system. 
This  unit  also  serves  as  the  central  coordinating  body  for  cross-divisional  and 
division  wide  system  and  program  design,  development  and  implementation.  This 
unit  is  responsible  for  the  review  and  approval  of  all  user  Requirements, 
Documents,  System  Design  Documents  and  System  Specification  Documents. 
This  unit  is  responsible  for  all  revenue  analysis,  tracking,  and  the  reconciliation  of 
all  accounts.  This  unit  is  responsible  for  the  design  and  development  of  a 
comprehensive  workload  tracking  system.  Also  included  in  this  unit's 
responsibilities  is  the  preparation,  coordination  and  distribution  of  PVPMISS 
related  Requests  for  Proposals. 
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5.        Planning  and  Technical  Development 


This  unit  is  primarily  involved  in  systems  and  program  design,  development  and 
implementation,  as  well  as  providing  technical  support  for  the  Divisions  Local 
Area  Network  (LAN)  and  Wide  Area  Network  (WAN).  This  includes  developing, 
designing  and  implementing  systems  and  programs  in  such  areas  as;  voice  response 
system  applications,  dispute  resolution,  ticket  processing,  payment  processing, 
booting/release  and  noticing.  Other  functions  include  formal  and  informal  staff 
training  and  coordinating  projects  that  deal  with  improvements  or  enhancements  to 
the  current  operating  systems.  This  unit  also  coordinates  special  collection  efforts, 
the  Government  Vehicle  Program,  Nixie  analysis,  and  acts  as  liaison  to  all  other 
parking  ticket  issuing  agencies.  The  Planning  unit  is  responsible  for  printing, 
warehousing,  ordering  and  the  periodic  redesign  of  the  parking  ticket  and  notices. 
This  unit  also  is  involved  with  the  design,  development  and  revision  of  BTD/OPC 
staff  manuals  to  inform  employees  of  new  procedures  and  policies  relative  to  the 
PVPMISS.  Also  included  in  this  unit's  responsibilities  is  the  development  of 
annual  programmatic  goals  and  objectives,  a  related  monthly  monitoring  effort  that 
documents  progress  towards  achieving  the  goals  and  objectives. 


(2.5.2)  Other  BTD  Divisions  Most  Directly  Involved  with  the  PVPMISS 

The  Enforcement  Division  (200  Frontage  Road,  South  Boston)  is  responsible  for 
parking  violation  issuance,  violation  towing,  parking  violation  booting  and  towing, 
abandoned  vehicle  towing,  vehicle  disposition  and  other  parking 
enforcement/management  activities.  Staff  in  this  unit  are  also  responsible  for 
processing  payments  through  two  of  the  real  time  on-line  cashiering  workstations. 
Note:  Other  City,  and  non-City,  agencies  also  issue  parking  violations.  The  percentage 
break  down  of  tickets  issued  are  as  follows: 

The  Transportation  Department  (Enforcement  Division)  presently  issues 
approximately  93%  of  all  parking  tickets; 


The  Boston  Police  Department  issues  approximately  6%,  and; 


The  remaining  1%  are  issued  by  ten  to  fourteen  other  agencies. 
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The  Operations  Division  (112  Southampton  Street,  Boston)  is  responsible  for  signals, 
sign  and  meter  operations  and  maintenance.  The  Meter  Unit  must  also  maintain  and 
update  the  Meter  Management  System  for  all  reported  meter  outages  and  repairs.  Both 
the  Meter  and  Sign  units  perform  verifications  to  assist  OPC  in  resolving  parking  ticket 
disputes.  The  Meter  Unit  performs  verifications  to  determine  the  operational  status  on 
meters  with  no  recent  repair/outage  updates,  and  the  Sign  Unit  performs  verifications 
relative  to  the  type,  location  and  installation  status  of  signs. 


The  Traffic  Management  Division  (Room  721,  Boston  City  Hall)  is  responsible  for  a 
myriad  of  activities  relating  to:  traffic  and  parking  rules  and  regulations  (signals, 
signage,  one  ways,  peak  hours,  traffic  counts,  time  delay/turnover,  pavement  and 
crosswalk,  markings,  snow  emergencies,  accident  research),  intergovernmental 
operations  coordination  (Public  Improvement  Commission/Engineering,  Department  of 
Public  Works  coordination  including  street  reconstruction,  street  cleaning  and  snow 
emergencies),  and  construction/street  management  (street  occupancy,  parade,  etc., 
permits,  inspection  and  monitoring,  project  acceptance). 


(2.5.3)  External  Agencies 

Massachusetts  Registry  of  Motor  Vehicles  (RMV)  —  This  agency  is  critical  to  the 
PVPMISS  in  the  violator  identification  process.  The  PVPMISS  Vendor  obtains  from 
the  RMV  names  and  addresses  of  the  registered  owners  of  the  plates  to  which  parking 
tickets  were  issued.  The  RMV  is  also  an  essential  participant  in  the  license/registration 
non-renewal  program. 


Out  of  State  Registry  of  Motor  Vehicles  (RMVs)  —  These  agencies  are  critical  to  the 
PVPMISS  in  the  violator  identification  process.  The  PVPMISS  Vendor  obtains  from 
the  RMVs  names  and  addresses  of  the  registered  owners  of  the  plates  to  which  parking 
tickets  were  issued. 


25 


26 


SECTION  3.0 


PROPOSAL  INFORMATION  AND  CONDITIONS 


27 


SECTION  3.0 
PROPOSAL  INFORMATION  AND  CONDITIONS 


This  section  outlines  general  conditions  and  provides  information  under  which  the 
proposal  shall  be  made. 

(3.1)  Term  and  Scope  of  Contract 

The  contract  entered  into  pursuant  to  this  RFP  shall  be  for  an  initial  term  of  twelve  (12) 
months,  commencing  July  1,  2010,  and  ending  June  30,  2011,  with  options  on  the  part 
of  the  City  to  renew  for  two  (2)  successive  twelve  (12)  month  periods  ending  on  June 
30,  2013. 


(3.2)  Approval  By  Mayor  and  CPO  (Designee)  Required 

Any  contract  awarded  pursuant  to  this  RFP  shall  be  subject  to  approval  by  the  City's 
Transportation  Commissioner  /  Parking  Clerk  and  the  Mayor. 


(3.3)  Subject  to  Appropriation 

Any  contract  awarded  pursuant  to  this  RFP  shall  be  subject  to  the  availability  of  an 
appropriation  in  each  fiscal  year  of  the  contract. 


(3.4)  Renewal  Subject  to  Investigation 

The  City  shall  not  exercise  its  option  for  renewal  for  the  contract  entered  into  as  a  result 
of  this  RFP  unless  the  BTD  Commissioner/Parking  Clerk,  after  reasonable  investigation 
of  costs  and  benefits,  has  determined  that  the  exercise  of  the  option  is  more 
advantageous  than  alternative  means  of  procuring  comparable  services. 


(3.5)  Applicable  Laws 

This  Request  for  Proposals  (RFP)  and  the  evaluation  of  proposals  received  subsequent 
to  the  release  of  the  RFP  will  be  governed  by  applicable  provisions  of  general  and 
special  laws  and  ordinances  including,  without  limitation,  Chapter  30B  of  the 
Massachusetts  General  Laws  (Chapter  30B)  and  contract  procurement  provisions  of  the 
City  of  Boston  Charter. 

Proposers  who  wish  to  review  the  provisions  of  Chapter  30B  can  do  so  at  the  MA  State 
House  Library,  at  a  law  library,  or  consult  with  their  legal  counsel. 

Manuals  containing  a  discussion  of  Chapter  30B  may  be  obtained  from  the  State 
Library: 

State  Library 
Room  304 
State  House 

Boston,  MA  02133  Phone  (617)  727-2590 


28 


(3.6)  General  RFP  Conditions 


The  City  will  award  the  contract  entered  into  pursuant  to  this  RFP  to  that  responsible 
and  responsive  proposer  whose  proposal,  conforming  to  this  RFP,  may  be  deemed  by 
the  City  to  be  most  advantageous  and  otherwise  in  the  City's  best  interest,  price  and 
other  factors  considered. 

This  RFP  does  not  commit  the  City  to  award  a  contract  to  any  proposer.  The  City  may 
cancel  the  RFP  at  any  time  until  the  proposals  are  opened.  Once  proposals  have  been 
opened,  the  City  may  reject  all  proposals  or  parts  thereof  at  any  time  before  an  award  is 
made.  The  City  may  cancel  the  RFP  or  reject  the  proposals  or  parts  thereof  if  it 
determines  that  such  action  is  in  the  City's  best  interest. 

However,  the  City  will  state  in  writing  the  reason  for  any  cancellation  or  rejection.  The 
City  reserves  the  right  to  waive  any  defects,  informalities,  and  minor  irregularities  in  the 
proposals  received. 


(3.7)  Proposer's  Examination  of  the  RFP 

Proposers  shall  examine  and  familiarize  themselves  with  all  information  and  materials 
contained  in  this  RFP  such  as  scope  of  services,  conditions,  evaluation  methodology 
and  criteria.  These,  and  other  pertinent  requirements,  are  an  integral  part  of  this  RFP. 
Ignorance  of  the  conditions  and  requirements  of  this  RFP  will  not  be  accepted  as 
excusable  under  any  circumstance.  By  filing  a  proposal  the  proposers  do  thereby 
represent,  under  the  pains  and  penalties  of  perjury,  that  they  have  so  informed 
themselves.  Failure  to  do  so  shall  be  at  the  proposer's  risk. 


(3.8)  Compliance  With  Proposal  Submission  Procedures 

Each  proposer  must  comply  with  all  requirements  of  this  RFP.  Proposals  which  do  not 
comply  may  be  rejected  immediately. 


(3.9)  Terminology 

Terms  used  in  this  RFP  are  not  intended  to  imply  or  denote  a  particular  proposer  and  are 
not  to  be  construed  as  restrictive  in  any  way. 


(3.10)  Prior  Information 

Any  information  which  may  have  been  released  either  orally  or  in  writing  prior  to  the 
issuance  of  the  RFP  shall  be  deemed  preliminary  and  binding  upon  neither  the  City  nor 
the  proposer. 
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(3.11)  Awarding  Authority/Evaluation  Committee 


This  RFP  is  issued  by  the  City  of  Boston's  Transportation  Department/Office  of  the 
Parking  Clerk.  An  evaluation  will  be  performed  by  an  Evaluation  Committee 
comprised  of  members  of  the  Boston  Transportation  Department/Office  of  the  Parking 
Clerk,  who  will  have  primary  responsibility  for  reviewing  and  evaluating  all  non-price 
(technical)  proposals  submitted  in  response  to  the  RFP,  and  shall  make  non-binding 
recommendations  to  the  chief  procurement  officer  designee  for  this  RFP,  who  shall  be 
Thomas  J.  Tinlin,  Commissioner/Parking  Clerk  of  the  Transportation  Department. 

The  designated  Chairperson  of  the  Evaluation  Committee,  and  the  person  to  whom  all 
inquiries  should  be  directed,  is: 

Gina  Fiandaca 
Director 

Office  of  the  Parking  Clerk,  Room  224 
One  City  Hall  Plaza 
Boston,  MA  02201 

Telephone  #:  Voice  (617)  635-4426;  Fax  (617)  635-4422 

In  the  event  the  above  named  individual  is  not  available,  inquiries  may  be  directed  to: 
Patrick  McHugh 

Office  of  the  Parking  Clerk,  Room  224 
One  City  Hall  Plaza 
Boston,  MA  02201 

Telephone  #:  Voice  (617)  635-4251;  Fax  (617)  635-4422 

A  determination  of  the  most  advantageous  proposal  from  a  responsible  and  responsive 
proposer  shall  be  made  taking  into  consideration  price  and  the  evaluation  criteria  set 
forth  in  the  RFP. 


(3.12)  Procedures  for  Opening  and  Evaluating  the  Price 
and  Non-Price  (Technical)  Proposals 

THE  CITY  OF  BOSTON  REQUIRES  SEPARATE  AND  SEALED  PRICE  AND 
NON-PRICE  (TECHNICAL)  PROPOSALS. 

The  non-price  (technical)  proposals  will  be  opened  in  closed  session  by  the 
Commissioner/Parking  Clerk  of  the  Boston  Transportation  Department,  or  his  designee, 
in  the  presence  of  one  or  more  witnesses,  following  the  appointed  final  date  and  time 
for  submitting  proposals.  At  the  time  of  the  opening,  the  City  will  prepare  and  make 
allowable  for  public  inspection  a  register  of  proposals,  which  shall  include  the  name  of 
each  proposer  and  the  number  of  proposal  modifications  submitted  by  each  proposer. 
The  City  will  also  record  the  names  of  the  witness(es). 


The  price  proposals  may  be  opened  by  the  City  immediately  after  opening  the  technical 
(non-price)  proposals  or  at  a  later  time.  However,  the  City  will  not  disclose  the  price 
proposals  to  the  evaluators  until  the  latter  have  completed  their  technical  (non-price) 
proposal  evaluations.  The  separation  of  technical  (non-price)  and  price  proposals  is  an 
important  element  of  the  RFP  process  and  proposers  must  fully  comply  with  this 
requirement. 
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The  contents  of  each  proposal  submitted  will  be  kept  confidential  and  not  disclosed  to 
competing  proposers  until  the  evaluation  process  is  completed  or  until  the  time  for 
acceptance  specified  in  the  RFP,  whichever  occurs  first. 


(3.13)  Tentative  Schedule  of  Events 

The  City  plans  to  proceed  with  this  procurement  in  a  series  of  orderly  steps.  The 
tentative  schedule  that  follows  has  been  developed  in  order  to  provide  adequate 
information  for  proposers  to  prepare  definitive  proposals  and  to  permit  the  City  to 
consider  fully  all  of  the  various  factors  that  may  affect  its  decision.  Proposers  will  be 
notified  in  writing  of  any  changes. 


EVENT 

Release  of  Request  for  Proposals 

Proposers  Conference 

Final  Date  and  Time  for  Submitting 
Proposals 

Evaluation  of  Proposals 

Awarding  Authority  Decision 
Notification  to  Proposers 
Start  of  Contract 


DATE 

Monday,  December  21,  2009 
Wednesday,  January  27,  2010 

Wednesday,  February  17,  2010 
(by  12  Noon,  EST) 

Wednesday,  February  17,  2010  through 
Monday,  April  5,  2010 

Monday,  April  5,  2010 

Monday,  April  12,  2010 

Sunday,  July  1,  2010 


(3.14)  Awarding  Authority  Decision 

While  the  City  plans  to  proceed  with  this  RFP  in  accordance  with  the  above  schedule,  in 
no  event  will  written  notice  of  the  award  decision  be  given  to  the  selected  proposer  later 
than  ninety  (90)  days  from  the  final  date  for  submitting  proposals.  The  time  for 
acceptance,  i.e.,  the  awarding  authority  decision  will  be  extended  (beyond  90  days)  only 
when  all  the  proposers  agree  to  the  extension. 
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(3.15)  Mandatory  Proposers'  Conference 


A  conference  for  prospective  proposers  will  be  held  in  the  Boston  Redevelopment 
Authority  (BRA)  Board  Room  (Room  900)  on  the  ninth  floor  of  the  City  Hall,  One  City 
Hall  Square,  Boston,  at  10:00  A.M.,  Boston  time,  on  Thursday,  January  21,  2010. 
Attendance  at  the  proposers'  conference  is  mandatory.  Proposals  from  proposers 
who  are  not  represented  at  the  proposers'  conference  will  not  be  considered. 

Potential  subcontractors  and  parties  not  wishing  to  be  considered  as  a  single-point-of- 
responsibility  (potential)  Prime  Vendor  are  not  required  to  attend  the  proposers' 
conference. 

Answered  questions  deemed  to  materially  affect  the  interpretation  of  the  RFP,  and 
questions  not  resolved  at  the  proposers'  conference,  will  be  answered  in  writing  and 
provided  to  each  prospective  proposer  that  has  attended  the  Proposer's  Conference. 


(3.16)  OPC  Division  Tour/Walk-Through 

An  optional  guided  tour/walk-through  of  the  OPC  division  of  the  BTD  will  be 
conducted  for  prospective  proposers  (following  the  Proposers  Conference)  at  2:00  P.M., 
Boston  time,  on  Thursday,  January  21,  2010.  The  location  of  the  tour/walk-through 
shall  be: 

Boston  City  Hall 
One  City  Hall  Plaza 
Office  of  the  Parking  Clerk 
Room  224 
Boston,  MA 


(3.17)  Inquiries 

Prospective  proposers  may  submit  technical,  contractual,  or  procedural  questions 
concerning  this  RFP  to  the  Chairperson  of  the  Evaluation  Committee  at  the  address  set 
forth  in  paragraph  3.11  above.  These  questions  must  be  in  writing.  They  may  be 
mailed  or  delivered. 

The  Evaluation  Committee  will  review  and  consolidate  inquiries  received  before  the 
deadline  for  inquiries  set  forth  below.  Should  any  questions  and  the  corresponding 
answers  be  deemed  to  materially  affect  the  interpretation  of  the  RFP,  copies  of  the 
questions  and  answers  will  be  provided:  (a)  prior  to  the  Proposers'  Conference  (if 
applicable)  to  each  prospective  proposer  that  has  received  a  copy  of  the  RFP  documents 
from  the  City,  and;  (b)  on  any  dates  after  the  Proposers'  Conference  to  each  prospective 
proposer  that  attended  the  conference.  All  inquiries  sent  by  fax  must  be  sent  between 
the  hours  of  9:00  AM  and  4:00  PM,  Boston  time,  Monday  through  Friday,  excluding 
holidays. 
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No  questions  will  be  accepted  after  MONDAY,  FEBRUARY  8,  2010,  in  order  that 
equal  information  may  be  available  to  all  proposers.  Only  written  answers 
provided  to  proposers  will  be  binding. 


(3.18)  Restrictions  on  Contact  With  City  Personnel 

From  the  date  of  release  of  this  RFP  and  until  a  determination  is  made  and  announced 
regarding  the  selection  of  a  vendor/contractor  as  a  result  of  this  RFP  process,  and  for  the 
selected  proposer  until  a  contract  is  signed,  all  contacts  with  personnel  employed  by  or 
contracted,  and/or  associated  with  the  City  of  Boston,  Boston  Transportation 
Department,  Office  of  the  Parking  Clerk  division,  save  and  except  those  made  pursuant 
to  any  pre-existing  obligations,  must  be  approved  by  the  Chairperson  of  the  Evaluation 
Committee.  During  the  same  period,  no  prospective  vendor/contractor  shall  approach 
personnel  employed  by  or  contracted  to  the  City  of  Boston  or  Boston  Transportation 
Department  concerning  employment.  Violations  of  these  conditions  will  be  considered 
sufficient  cause  by  the  City  to  reject  a  proposer's  proposal  and/or  selection,  irrespective 
of  any  other  considerations. 

For  the  purpose  of  assembling  or  collaborating  on  a  proposal,  contact  with  contractors 
or  subcontractors  who  provide,  directly  or  indirectly,  any  PVPMISS  services  under  the 
current  PVPMISS  contract  is  allowed,  and  the  approval  of  the  Chairperson  of  the 
Evaluation  Committee  is  not  required. 

In  addition,  proposers  are  advised  that  only  the  Evaluation  Committee,  meeting  in  its 
official  capacity,  can  answer  questions,  clarify  issues,  or  render  any  opinion  regarding 
the  RFP.  No  individual  committee  member,  or  City  employee,  is  empowered  to  make 
binding  statements  regarding  this  RFP. 


(3.19)  Revisions  /  Addenda 

If  it  should  become  necessary  to  revise  any  part  of  this  RFP  or  otherwise  provide 
additional  information,  an  addendum  will  be  issued  by  the  City  and  furnished  to  all 
prospective  proposers  who  have  obtained  copies  of  this  RFP. 


(3.20)  Proposal  Deposit 

A  proposal  deposit  in  the  form  of  a  certified  check  drawn  on,  or  a  treasurer's  or  cashier's 
check  issued  by,  a  responsible  bank  or  trust  company  and  made  payable  to  the  City  of 
Boston,  or  a  proposal  bond  issued  by  a  surety  company  qualified  to  do  business  in  the 
Commonwealth  and  satisfactory  in  form  to  the  City,  must  accompany  the  signed 
original  Technical  Proposal  received  at  the  Transportation  Department/Office  of  the 
Parking  Clerk.  The  amount  of  such  check  or  the  penal  sum  of  such  bond  shall  be 
twenty-five  thousand  dollars  ($25,000).  Failure  to  include  a  proposal  deposit  as 
required  will  be  cause  for  disqualification  of  any  proposal  submitted.  The  proposal 
deposit  shall  be  included  with  the  original  signed  Technical  (non-price)  proposal. 
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(3.21)  Return  of  Deposit 


All  proposal  deposits,  except  those  of  such  proposers,  if  any,  still  under  favorable 
consideration  by  the  evaluators,  shall  be  returned  within  forty- five  (45)  days  (Saturdays, 
Sundays  and  legal  holidays  excluded)  after  the  deadline  for  submission  of  proposals. 
Remaining  proposal  deposits  shall  be  returned  only  upon  the  execution  and  delivery  of 
the  Contract  to  the  City  or,  if  no  award  is  made,  prior  to  the  expiration  of  ninety  (90) 
days  after  the  deadline  for  submission  of  proposals. 


(3.22)  Execution  and  Terms  of  Contract 

Following  notification  of  the  award  to  the  successful  proposer,  the  City  and  the 
successful  proposer  will  execute  a  written  contract  containing  by  reference  or  other 
means  all  the  terms,  conditions  and  specifications  set  forth  in  this  RFP. 

In  the  event  the  successful  proposer  fails,  neglects  or  refuses  to  execute  said  contract 
within  thirty  (30)  days  after  the  mailing  of  said  contract  to  said  proposer  at  its  address 
stated  in  its  proposal,  the  City  may  at  its  option  terminate  and  cancel  its  action  in 
awarding  said  contract  and  the  contract  shall  become  null  and  void  and  of  no  effect,  and 
the  City  may  award  the  contract  to  the  next  most  advantageous  proposer  or  the  City 
may  reissue  the  RFP. 

No  contract  between  the  City  and  the  successful  proposer  whose  proposal  is  accepted 
shall  exist  until  the  written  contract  shall  have  been  executed  by  it  and  the  City.  The 
City  will  not  execute  the  contract  until  insurance  certificates  and  bonds  and  other 
documents  required  by  the  contract  have  been  delivered  to  the  Awarding  Authority  in 
an  acceptable  form. 


(3.23)  Failure  to  Execute  Contract;  Liquidated  Damages 

If  the  successful  proposer  fails  to  perform  its  agreement  to  execute  a  contract  and 
furnish  the  required  security  for  performance  within  thirty  (30)  days  after  an  award  is 
made  by  the  City,  or  within  such  additional  time  as  the  Awarding  Authority  may 
authorize  in  writing,  the  proposer's  bid  deposit  shall  become  and  be  the  property  of  the 
City  of  Boston  as  liquidated  damages;  provided  that,  in  case  of  death,  disability,  bona 
fide  clerical  or  mechanical  error  of  a  substantial  nature,  or  other  unforeseen 
circumstances  affecting  the  proposer,  the  proposer's  bid  deposit  shall  be  returned  after 
submission  of  a  sworn  affidavit  delivered  to,  and  accepted  by,  the  City. 


(3.24)  Incurring  Costs 

The  City  shall  not  be  liable  for  any  costs  incurred  by  proposers  in  preparing,  submitting 
or  presenting  proposals,  or  in  satisfying  any  demonstration  or  other  requirements. 
Further,  the  City  shall  not  reimburse  any  costs  incurred  by  proposers  in  anticipation  of 
being  awarded  the  contract  under  this  RFP. 
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(3.25)  Note  Regarding  the  Same  Subcontractor  for  Different  Proposals 


In  the  event  that  subcontractors  for  any  services  are  identified  by  a  proposer  as 
providing 

that  service  for  that  particular  proposer's  proposal,  said  subcontractor  shall  not  be 
prohibited  by  the  terms  of  this  RFP  from  joining  with  another  proposer  in  the  submittal 
of  that  different  proposal. 


(3.26)  Performance  Bond 

The  City  requires,  as  security  to  guarantee  the  faithful  performance  of  any  contract 
awarded  pursuant  to  this  RFP,  a  performance  bond  of  a  surety  company  authorized  to 
do  business  in  Massachusetts  and  satisfactory  in  form  to  the  Awarding  Authority  in  the 
amount  of  one  million  dollars  ($1,000,000). 


(3.27)  Basis  for  Acceptance/Conflict  of  Interest 

Any  proposal  made  will  be  accepted  on  the  basis  that  the  proposer,  by  submitting  its 
proposal,  represents  that  it  is  made  in  good  faith  without  fraud,  collusion  or  connection 
of  any  kind  with  any  other  proposer  for  the  same  work;  that  the  proposer  is  competing 
solely  on  its  own  behalf  without  connection  with,  or  obligation  to,  any  undisclosed 
person,  firm  or  corporation;  that  no  other  person,  firm  or  corporation  will  have  any 
interest  in  the  contract;  that  no  officer,  agent  or  employee  of  the  City  is  financially 
interested  in  the  contract;  that  the  proposer  is  fully  informed  in  regard  to  all  provisions 
of  the  RFP,  including,  without  limitation,  the  specifications,  the  time  for  performance 
and  the  provisions  with  respect  to  liquidated  damages,  and  performance  bond  or  other 
security  if  any.  This  paragraph  shall  not  be  interpreted  to  exclude  or  in  any  manner 
prohibit  the  submission  of  proposals  from  two  or  more  firms  wishing  to  submit  a  joint 
proposal  in  response  to  this  RFP. 


(3.28)  Systems  Responsibility 

Notwithstanding  the  requirements  and  conditions  in  this  RFP,  it  is  the  responsibility  of 
the  proposer  to  verify  the  completeness  of  the  hardware,  software,  specifications, 
systems,  elements,  functionality  and  suitability  of  products  and  services  to  meet  the 
intent  of  this  RFP.  Any  additional  hardware,  software,  services,  etc.,  required  after 
installation,  even  if  not  specifically  mentioned  herein,  shall  be  provided  by  the  proposer 
without  claim  for  additional  payment,  it  being  understood  that  a  complete,  operating 
PVPMISS  is  required.  The  successful  proposer  shall  be  obligated  to  provide  a 
PVPMISS  that  meets  all  guarantees  in  its  proposal  for  the  price  contained  therein. 
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(3.29)  Rights  to  Submitted  Material 


All  proposals,  responses,  inquiries,  or  correspondence  relating  to  or  in  reference  to  this 
RFP,  and  all  reports,  charts,  displays,  schedules,  exhibits,  and  other  documentation 
submitted  by  proposers  shall  become  the  property  of  the  City  when  received. 

Supporting  technical  and  proprietary  manuals  will  be  returned  at  the  request  of  the 
proposer.  The  City  retains  the  right  to  use  any  or  all  system  ideas  presented  in  any 
proposal  in  response  to  the  RFP,  whether  amended  or  not.  Selection  or  rejection  of  any 
proposal  does  not  affect  this  right. 


(3.30)  Use  of  Proposals 

The  City  reserves  the  right  to  use  any  or  all  ideas,  concepts  or  configurations  presented 
in  a  proposer's  proposal,  whether  or  not  the  proposal  is  selected. 


(3.31)  Return  of  Proposals 

The  City  shall  be  under  no  obligation  to  return  any  proposals  or  materials  submitted  by 
a  proposer  in  response  to  this  RFP. 


(3.32)  Confidential/Proprietary  Information 

All  proposals  submitted  in  response  to  this  Request  for  Proposal  become  a  matter  of 
public  record  and  shall  be  regarded  as  public  records,  with  the  exception  of  those 
elements  in  each  proposal  which  are  defined  by  the  proposer  as  business  or  trade 
secrets,  and  plainly  marked  as  "Trade  Secret",  "Confidential"  or  "Proprietary".  The 
City  shall  not  in  any  way  be  liable  or  responsible  for  the  disclosure  of  any  such  records 
or  portions  thereof,  if  they  are  not  plainly  marked  as  "Trade  Secret",  "Confidential",  or 
"Proprietary",  or  if  disclosure  is  required  under  the  public  records  law.  If  a  third  party 
challenges  the  trade  secret,  confidential,  or  proprietary  nature  of  certain  information,  it 
will  be  the  responsibility  of  the  proposer  to  defend  that  challenge.  The  City  assumes  no 
responsibility  for  disclosure  or  use  of  unmarked  data  for  any  purpose. 


(3.33)  Proposals  Not  Selected 

Non-selection  of  any  proposal  will  mean  that  another  proposal  was  deemed  to  be  more 
advantageous  to  the  City  or  that  no  proposal  was  accepted.  Proposers  whose  proposals 
are  not  accepted  will  be  so  notified  in  writing. 


(3.34)  News  Releases 

Proposers  shall  at  no  time  make  any  news  or  advertising  releases  pertaining  to  this  RFP 
for  any  purpose  without  the  prior  written  approval  of  the  Parking  Clerk  and  then  only  in 
coordination  with  the  Parking  Clerk. 
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(3.35)  City  of  Boston  Jobs  and  Living  Wage  Ordinance 


Each  proposer  shall  be  required  to  abide  by  the  City's  Jobs  and  Living  Wage  Ordinance 
as  set  forth  herein  entitled  'CITY  OF  BOSTON  JOBS  AND  LIVING  WAGE 
ORDINANCE',  starting  on  page  number  507  of  this  RFP. 


(3.36)  Approval  of  Systems 

The  City  reserves  the  right  to  approve  all  software  systems  and  subsystems  before  they 
are  brought  into  the  Boston  production  environment.  To  this  end,  the  City  may  require 
that  all  design  specifications  be  approved  and  may  establish  appropriate  procedures  for 
testing  by  the  selected  proposer  of  the  systems  and  subsystems  before  final  approval  is 
given. 


(3.37)  Relationships  Between  Proposers 

Two  or  more  proposers  may  combine  to  submit  a  joint  proposal  in  response  to  this  RFP. 
One  of  the  proposers  must  be  designated  as  the  Prime  Vendor.  The  City  requires  single 
point  responsibility  for  the  entire  project.  Subcontractors  may  be  used  but  the  prime 
contractor,  i.e.,  Prime  Vendor,  must  accept  full  responsibility  for  the  subcontractor's 
performance.  All  subcontractors  must  be  identified  by  the  proposer  and  the  proposer 
must  describe  the  type  of  contractual  arrangement  that  will  exist  with  all  subcontractors 
and  provide  a  copy  of  any  subcontract  if  requested  by  the  City.  The  Prime  Vendor  shall 
be  responsible  for  meeting  all  the  terms  of  the  contract  resulting  from  this  RFP.  This 
provision  is  designed  to  ensure  that  an  integrated  and  comprehensive  PVPMISS  which 
includes,  among  other  things,  a  cash  processing  lockbox  operation  is  managed  in  a 
properly  controlled,  efficient  and  effective  environment. 


(3.38)  Plan  of  Services 

Each  proposer  must  provide  a  'plan  of  services'.  The  completed  plan  of  services  must 
be  included  with  the  proposers  response  to  this  RFP.  The  plan  of  services  will  contain 
specific  information  about  the  proposer's  internal  operations  or  management  systems 
which  relate  to  fulfilling  the  contract.  This  information  will  be  used  to  evaluate  the 
proposer's  ability  to  provide  equipment,  supplies  or  services  specified  in  the  purchase 
description.  The  primary  function  of  the  plan  of  services  is  to  help  enable  the  City  of 
Boston  to  evaluate  the  proposers'  ability  to  fulfill  the  terms  of  the  contract. 
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(3.39)  Negotiating  Changes  to  the  Plan  of  Services  with  the  Proposer  Submitting  the 
Most  Advantageous  Proposal 

The  City  may  condition  the  contract  award  on  successful  negotiation  of  revisions  to  the 
plan  of  services  identified  by  the  evaluators  during  the  proposal  evaluation  phase  of  the 
process.  The  scope  of  these  negotiations  is  strictly  limited.  Only  the  plan  of  services  is 
subject  to  negotiation;  the  RFP  specifications,  scope  of  services,  contract  terms,  and  the 
price  proposal  are  not  negotiable.  The  City  may  not  agree  to  pay  more  than  the 
proposal  price  nor  may  the  City  agree  to  indirect  price  adjustments:  e.g.,  reductions  in 
the  scope  of  services,  the  proposer's  responsibilities,  or  the  quality  of  the  product. 
Allowing  a  proposer  to  change  the  proposal  price  or  any  other  RFP  requirement  after 
the  proposals  have  been  opened  is  a  violation  of  Chapter  30B. 


(3.40)  Debriefing 

Any  proposer  may  have  a  debriefing  by  requesting  it  in  writing  within  fifteen  (15)  days 
of  having  received  notice  that  it  was  not  selected  under  this  RFP.  The  debriefing  will 
be  conducted  by  the  Evaluation  Committee,  which  will  only  discuss  its  evaluation  of  the 
proposer's  proposal;  competing  proposals  will  not  be  discussed.  Debriefing  requests 
shall  be  addressed  to  the  Chairperson  of  the  Evaluation  Committee. 


(3.41)  Tax  Exempt  Status 

The  City  qualifies  as  a  political  subdivision  of  a  State  of  the  United  States  for  purposes 
of  Section  103(a)  of  the  Internal  Revenue  Code  of  1986,  and  is  exempt  from  state  and 
local  income  taxation,  from  federal  excise  taxes,  and  from  Massachusetts  sales  tax. 
These  taxes  should  not  be  included  in  the  proposer's  prices. 
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SECTION  4.0 


SCOPE  OF  SERVICES 
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SYSTEM.  OPERATIONAL  AND  FUNCTIONAL  REQUIREMENTS 
OF  A  COMPREHENSIVE  AND  INTEGRATED  PVPMISS 
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4.1  SYSTEM.  OPERATIONAL  AND  FUNCTIONAL  REQUIREMENTS 
OF  A  COMPREHENSIVE  AND  INTEGRATED  PVPMISS 


(4.1.0)  Overview 

System  and  operational  requirements  of  the  PVPMISS  are  defined  throughout  this  RFP 
to  reflect  the  functional  needs  of  the  PVPMISS.  Identified  areas  of  requirements 
include,  by  way  of  example: 

-  Ticket  Processing 

-  Ticket  Data  Entry 

-  User-Friendly  Ticket  and  Other  Transaction  Update  System  and  Processing 

-  Lockbox  Processing  and  Payment  Processing 

-  User-Friendly  On-Line  Payment  System  and  Processing 

-  User-Friendly  On-Line  PVPMISS  Access  and  Inquiry  System 

-  User-Friendly  and  Comprehensive  On-Line  Customer  Service  System  and 
Processing  (which  includes  Correspondence  Processing,  Hearing  Scheduling, 
Hearing  Officer  Administration,  Lease/Rental  Vehicle  Processing,  Fleet  Vehicle 
Processing,  Suspend  Processing,  etc.) 

-  User-Friendly  and  Comprehensive  Imaging  and  Workflow  Application 

-  Dunning,  Customer  Service,  Resident  Parking,  Hearing,  Abandoned  Vehicle 
Notice  Generation  and  Processing 

Utilization  of  Zip  Code  Sorting  Software  and  Bar  Codes  and  Mail  House 
Processing 

-  Massachusetts  and  Out-of-State  Registry  of  Motor  Vehicles  Interface  and 
Processing 

User-Friendly  On-Line  Access  and  Non-Renewal  Processing  to  the  Massachusetts 
Registry  of  Motor  Vehicles 

-  User-Friendly  Parking  Meter  System  and  Status  Processing 

-  Sign  System  and  Status  Processing 

-  User-Friendly  Seizure  and  Tow  System  and  Processing  Including  Utilization  of 
Hand-Held  'Seizure  Identification  System  and  Device' 

-  User-Friendly  Abandoned  Vehicle  System  and  Processing 

-  User-Friendly  Customer  Service  Interactive  Voice  Response  System 

-  User-Friendly  Pay-By-Phone  Interactive  Voice  Response  System 

-  User-Friendly  Pay-By- Web  System 

-  User-Friendly  Management,  Financial,  Processing,  Reconciliation  Operations  and 
Activity  Reporting  Systems  and  Reports 

-  Systems  Modification  and  Development 

-  Local  and  Wide  Area  Networks  linked  to  City  Network  and  Integration  of 
PVPMISS  and  Related  Applications 

-  On-Line  Resident  Permit  Parking  System 

-  On-Line  Refund  System  with  Interface  to  City's  Related  Application 

-  Traffic  Management  Permitting  Systems 

-  On-Line  Ticket  Archive  System 

-  On-Line  Stolen  Vehicle  Record  System 
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The  Vendor  is  required  to  provide  a  proven,  turn-key  (complete  readiness  for  operation 
effective  July  1,  2010)  and  comprehensive  computer  based  system  of  all  tickets  and 
license  plates  integrated  with  all  data  required  to  support  all  system  components. 

Data  for  all  programs  and  systems  must  be  maintained  within  an  integrated  database, 
with  relationships  established  to  allow  retrieval  and  update  of  related  information  across 
program  areas  in  an  efficient,  effective  and  error-free  manner.  The  PVPMISS  and 
related  systems  or  system  functions  and  responsibilities  of  the  Vendor  must  have 
maximum  functionality  and  integrate  systems  and  system  elements  as  described  in  this 
RFP. 

The  Vendor's  database  design  and  software  (as  well  as  hardware)  must  be  constructed 
to  accommodate  the  volumes  and  scheduling  considerations  set  forth  in  this  RFP. 

It  is  extremely  important  that  the  Vendor's  database  design  and  software  is  sufficiently 
flexible  and  modular  to  accommodate  easy/simple,  efficient  and  effective  modification 
or  expansion  of  existing  applications  —  and  to  accommodate  efficient  and  effective 
development  and  implementation  of  new  applications.  Equally  important,  said 
modifications,  expansions  or  developments  must  eliminate  or  extremely  minimize  any 
risk  to  the  quality  of  performance  or  operation  of  existing  applications  and  functions. 


(4.1.1)  Functional  Requirements  and  Features 

The  Vendor  is  required  to  provide  a  PVPMISS  that,  as  a  minimal  requirement,  includes 
the  below-listed  functions  and  features.  Further,  the  PVPMISS  required  must 
efficiently  and  effectively  accommodate  and  provide  for  the  maximum  integration  of 
these  and  other  functions  and  features: 


a)  The  automatic  calculation  and  assessment  of  penalties  to  violations  not  paid 
within  time  limits  and  under  certain  conditions. 

b)  The  automatic  backing-out,  holding  in  abeyance,  reactivating  of  penalties  under 

numerous  valid  conditions. 

c)  Evaluate  current  activity  and  determine  what  type  of  date  or  condition  based 

activity  needs  to  take  place  on  a  violation  and  calculate  when  that  activity 
should  occur,  e.g.,  name  and  address  request,  non-renewal  hold,  etc. 

d)  Re-evaluate  scheduled  activities  in  light  of  on-line  and  batch  transactions. 

e)  Predetermined  time  based  activities  should  be  performed  by  the  system  and  the 
violation  status  should  be  updated  for  the  next  appropriate/applicable  event. 

f)  Assess  and  re-assess  status  of  a  registration  based  on  number  of  tickets,  number 
of  unpaid  tickets,  number  of  unpaid  tickets  that  appear  on  a  specific  notice,  and 
number  of  tickets  with  issue  dates  within  specific  time  limits. 
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g)  Interface  with  various  systems,  subsystems  or  system  elements. 

h)  Interface  with  any  system,  subsystem  or  system  element  shall  be  automated  and 
data  edit  and  verification  processes  shall  be  comprehensive. 

i)  Conduct  real-time  editing  of  transactions  entered  through  the  on-line 
environment. 

j)   Update  the  ticket  database  in  a  real-time  mode  with  on-line  transaction 
information. 

k)  For  each  violation  maintain  a  "history"  of  system  generated  events  and 
processing  transactions  that  can  be  viewed  on-line. 

1)    System  must  facilitate  license  plate  level  payment  processing  and  license  plate 
level  transactions. 


(4.1.2)  Note  to  Proposers: 

The  City  is  extremely  interested  in  proposer  responses  to  the  above  requirements.  In 
addition,  while  requirements  identified  in  this  RFP  for  a  particular  functional  area  and 
system  element  also  include  the  relationship  to  other  functions  and  system  elements,  the 
City  requires  that  prospective  Vendors  address  and  describe  these  requirements  in  terms 
of  the  level  of  integration  of  their  'whole'  or  'aggregate'  PVPMISS. 

Toward  this  end,  prospective  Vendors  are  required  to  describe  the  design  and 
functionality  of  their  PVPMISS  in  terms  of: 

the  requirements  set  forth  in  this  section 

-  data  management 

-  how  data  items  are  related  to  each  other 

-  the  file  structure/data  structure  utilized  by  the  software  system 

the  organization,  coherence,  linkage  and  unity  of  the  various  constituent  system 
elements 

handling  the  large  number  and  numerous  types  of  transactions 

-  the  capabilities  and  means  of  scheduling  and  producing  transactions,  events  and 

activities  on  very  flexible  schedules,  e.g.,  the  production  of  the  same  notice  type 
on  a  daily  basis  at  various  quantity  levels  specified  by  the  City,  and 
flexibility  and  ease  of  modification  and  enhancement. 

This  description  must  also  include  those  portions  of  a  proposer's  PVPMISS  that 
actually  execute  actions  and  events,  i.e.,  the  'do-er(s)'  of  the  system. 
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(4.2)  CHANGES  TO  SPECIFICATIONS  AND  REQUIREMENTS  AND 

THE  EFFECTIVE  AND  EFFICIENT  ACCOMMODATION  OF  CHANGES 


The  City  reserves  the  right  to  change  or  modify  any  specifications  and  requirements 
relating  to  the  items  set  forth  in  this  RFP.  This  shall  include  the  identification  of  new 
specifications  and  requirements. 

The  Vendor  is  completely  obligated,  as  an  inherent  and  inalienable  responsibility  under 
this  RFP,  to  accept  and  efficiently  and  effectively  act  upon  any  such  changes  or 
modifications. 

The  Vendor's  PVPMISS  must  be  able  to  fully  support  improvements  and  expansions, 
by  way  of  example,  in  the  areas  of  parking  violation  processing,  related  transportation 
and  parking  management  activities,  registrant  data  acquisition  and  RMV  interface, 
public  inquiry  response  and  processing,  adjudication,  collections,  audit  trails  and 
controls  on  all  activities  and  transactions,  management  reporting,  and  management 
services  that  are  set  forth  in  this  RFP. 

The  Vendor's  PVPMISS  must  have  a  high  degree  of  flexibility  to  accommodate  minor 
and  major  system  modifications  and  enhancements,  in  particular,  the  addition  of  new 
data  elements,  new  on-line  inquiry  and  processing  screens,  new  on-line  inquiry 
capabilities,  and  new  on-line  and  batch  processing  capabilities. 

Further,  the  Vendor  must  be  able  to  provide  technical  assistance  and  the  necessary 
resources  to  expand  and  enhance  existing  systems  and  operations  and  develop  and 
implement  new  activities  and  programs. 

The  need  for  flexibility  regarding  specifications  and  requirements  is  unavoidable  and 
integral  to  this  RFP  because  change  is  inevitable  in  the  PVPMISS  environment  that 
Boston  operates  within.  Therefore,  the  right  to  change,  modify  or  add  to  specifications 
and  requirements  is  inalienable  to  this  RFP. 

The  need  for  flexibility  will  arise  from  any  number  of  combinations  of  factors.  For 
example: 

Public  policy  makers  will  initiate  laws,  statutes,  regulations  or  agendas  that  impact 
existing  specifications  and  requirements  or  that  require  new  specifications  and 
requirements; 

Any  number  of  events  will  occur  or  trends  will  develop  that  result  in  new 

responsibilities  or  that  call  for  new  approaches  to  existing  responsibilities; 

RMVs  can  change  or  modify  their  EDP  and  other  systems  and  procedures; 

The  City's  fundamental  commitment  to  on-going  and  incremental  improvements  to 
existing  systems  will  result  in  the  identification  and  implementation  of  new 
systems  or  system  elements; 

The  City's  selection  of  a  Vendor  that  is  fundamentally  committed  to  on-going  and 
incremental  improvements  to  existing  systems  will  result  in  the  identification 
and  implementation  of  new  systems  or  system  elements. 
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The  City  requires  that  all  systems,  subsystems  and  system  elements  of  the  Vendor's 
PVPMISS  be  able  to  accommodate  changes,  modifications  or  additions  in  a  highly 
efficient  and  effective  manner. 

While  high  quality  of  systems  and  system  elements  is  the  required  end  result,  of  great 
importance  is  the  turnaround  time  to  effect  changes,  modifications  or  new 
developments. 

The  fact  that  highly  advantageous  turnaround  time  of  high  quality  systems  and  system 
elements  must  often  be  achieved  in  a  multiple  project  environment  further  dictates  that 
the  Vendor's  PVPMISS  can  be  efficiently  and  effectively  changed,  modified  or  added 
to. 

With  the  exception  of  'Ticket  Data  Entry'  and  'Microfilm'  or  any  other  items  otherwise 
specified,  VENDOR  COMPENSATION  FOR  ALL  SYSTEMS  AND  SERVICES 
SET  FORTH  IN  THIS  RFP,  INCLUDING  CHANGES  AND  MODIFICATIONS. 
IS  TO  BE  INCLUDED  IN  THE  'COMPREHENSIVE  PER  TICKET  PRICE'  SET 
FORTH  IN  THE  PRICE  SECTION  OF  THIS  RFP.  IT  SHOULD  BE  CLEARLY 
UNDERSTOOD  THAT  THE  CITY  WILL  NOT  ENTERTAIN  REIMBURSABLE 
'CHANGE  ORDERS',  ETC.,  FOR  SOFTWARE  COMPUTER  SYSTEM 
CHANGES  OR  OTHER  CHANGES  INVOLVING  ITS  PVPMISS. 

IT  ALSO  SHOULD  BE  CLEARLY  UNDERSTOOD  THAT  THIS  CONTRACT 
IS  NOT  A  SYSTEM  DEVELOPMENT  CONTRACT  FOR  A  PVPMISS.  UNLESS 
SPECIFIED  OTHERWISE,  THE  CITY  EXPECTS  AND  REQUIRES  THAT 
SPECIFIED  SYSTEMS,  APPLICATIONS  AND  PROCESSES  AND  OTHER 
REQUIREMENTS  BE  FULLY  OPERATIONAL  IN  A  HIGHLY  EFFICIENT 
AND  EFFECTIVE  MANNER  ON  THE  EFFECTIVE  DATE  OF  THE 
CONTRACT. 


The  City's  rationale  and  demand  for  a  PVPMISS  with  maximum  features  and 
capabilities  in  combination  with  highest  level  of  quality  should  be  clearly  understood 
due  to  the  obvious  critical  and  sensitive  customer  service  and  revenue  aspects  of  the 
PVPMISS.  Moreover,  the  City  demands  that  in  addition  to  the  turnkey  operation  of  the 
most  superior  PVPMISS,  the  PVPMISS  will  be  maintained,  modified  and  enhanced 
throughout  the  contract  period.  As  a  result,  prospective  vendors  should  be  aware  of  the 
following: 

The  expected  and  necessary  flexibility  of  the  Vendor's  PVPMISS  should  allow  for 
efficient  commitment  of  vendor  resources; 

The  number  and  types  of  PVPMISS  personnel  committed  by  and/or  available  to  the 
Vendor  is  expected  to  be  able  to  accommodate  on-going  and  routine  client 
demand  for  change  and  modification  services; 

The  number  and  types  of  PVPMISS  personnel  committed  by  and/or  available  to  the 
Vendor  is  expected  to  be  able  to  accommodate  substantial  change  and 
modification  services  and/or  atypical  client  surges  in  demand  for  services; 
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The  product  of  required  changes  and  modifications  would  often  be  of  mutual  benefit 
in  that  said  product  would  be  utilized  by  the  Vendor's  other  clients  and/or 
marketed  by  the  Vendor; 

In  a  multiple  project  environment,  while  demanding  performance  excellence  in 
terms  of  effectiveness  and  timeliness  of  completion,  the  City  recognizes  the 
value  of  project  prioritization; 

-    The  Vendor  can  expect  the  City  to  be  an  active  and  involved  system  'user'  and  to 
contribute  its  collective  PVPMISS  knowledge  in  light  of  desired  objectives 
toward  the  development  of  functionality  and  specifications. 


THE  IMPORTANCE  OF  THE  ABOVE  CONDITIONS  TO  THE  CITY  AND  THEIR 
COMPLETE  ACCEPTANCE  BY  THE  VENDOR  CANNOT  BE  OVERSTATED. 
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(4.3)  PARKING  TICKET  PICK-UP.  RECEIPT  AND  CONTROL 


(4.3.1)  Issuance  Profile 

Currently,  more  than  fifteen  (15)  agencies  are  authorized  to  issue  parking  violation 
tickets  in  the  City  of  Boston.  In  addition,  each  of  the  six  divisions  of  the  Boston  Police 
Department  issues  parking  tickets. 

Boston  Transportation  Department  (BTD)  personnel  currently  issue  the  vast  majority  of 
parking  tickets,  accounting  for  90%  to  95%  of  tickets  annually.  Additionally,  the  vast 
majority  of  parking  tickets  are  issued  electronically.  However,  the  requirements  listed 
here-in  should  be  considered  important  and  serve  to  underscore  the  City's  perspective 
of  the  handling  of  such  items. 


(4.3.2)  Ticket  Retrieval  and  Receipt 

The  Vendor  shall  provide  a  bonded  courier  to  retrieve  tickets  issued  by  the  BTD  from 
the  BTD  Enforcement  Division  facility  currently  located  at  Frontage  Road.  Said 
retrieval  shall  occur  on  a  daily  basis  (Monday  through  Friday)  and  shall  be  completed 
no  later  than  11:00  A.M.  of  each  day. 

All  other  organizations  authorized  to  issue  parking  tickets  shall  be  responsible  for 
delivering  tickets  to  the  Vendor  on  a  daily  basis.  The  Vendor  shall  accommodate  said 
delivery  of  tickets,  at  a  minimum,  between  the  hours  of  8:00  A.M.  and  5:00  P.M. 
(Monday  through  Friday). 


(4.3.3)  Counting.  Batching  and  Control 

The  Vendor's  Boston  office  shall  be  open  and  staff  shall  be  available  to  receive,  count 
and  batch  the  delivered  tickets  during  normal  business  hours  -  8:00  A.M.  to  4:00  P.M. 
or  9:00  A.M.  to  5:00  P.M.,  Monday  through  Friday,  normal  City  workdays/workweeks. 

Prior  to  retrieval  by  the  Vendor's  courier,  the  BTD  shall  machine  count  the  number  of 
tickets  to  be  transmitted,  separately  group  tickets  for  the  purpose  of  reconciliation  and 
control,  and  note  the  number  of  tickets  counted  on  a  reconciliation  form.  The  BTD  will 
provide  this  form  to  the  Vendor's  courier  at  the  time  of  ticket  retrieval  by  the  courier. 

Upon  delivery  of  tickets  to  the  Vendor  worksite  by  the  courier,  the  Vendor  will  be 
responsible  for  machine  counting  (and,  if  necessary,  re-batching)  the  tickets  in 
accordance  with  specifications  determined  by  the  City.  Currently,  the  Vendor  must 
batch  the  tickets  into  groups  of  one  hundred  (100). 

The  Vendor  shall  also  be  responsible  for  performing  counts  and  batching  of  tickets  that 
are  submitted  to  the  Vendor  by  other  issuing  organizations. 

For  each  batch,  the  Vendor  will  be  required  to  prepare  a  batch  header  card  with 
information  that  includes  the  julian  date,  the  batch  number,  number  of  tickets  in  the 
batch  and  the  issuing  agency/division  that  issued  the  tickets. 


55 


The  Vendor  will  be  responsible  for  providing  positive  controls  for  reconciling 
differences  between  an  Issuing  Agency's  and  the  Vendor's  count  and  batch  totals.  The 
Vendor  is  responsible  for  identification  of  any  discrepancies.  The  Vendor  must  notify 
the  Issuing  Agency  and  the  BTD/OPC  monitoring  unit  of  any  discrepancies. 

The  Vendor  shall  be  responsible  for  providing  comprehensive  and  strong  quality  control 
measures  to  ensure  the  accurate  and  timely  handling  of  tickets  received  from  issuing 
agencies. 


(4.3.4)  Subsequent  Handling  of  Tickets 

The  Vendor  shall  be  responsible  for  the  safe  and  controlled  delivery  of  tickets  to  the 
Data  Entry  function  facility  and  the  Scanning  function  facility. 

The  Vendor  shall  be  responsible  for  identifying  and  reconciling  any  differences  in 
counts  of  tickets  between  the  Vendor's  ticket  receipt  function  and  the  Data  Entry  and 
Scanning  functions. 


(4.3.5)  Reporting 

The  Vendor  shall  be  responsible  for  compiling  data  on  a  daily  basis  and  submitting  a 
weekly  two  page  report  document  reflecting:  (a)  daily  and  weekly  ticket  receipts  by 
agency,  and  (b)  the  issuance  dates  (issuance  range)  of  the  earliest  and  most  recent  ticket 
contained  in  an  agency's  daily  submittal. 

The  Vendor  shall  also  provide  daily  reports  on  request. 


(4.3.6)  Capacity 

Depending  upon  numerous  factors,  the  number  of  tickets  that  will  be  turned  in  on  a 
typical  daily  basis  is  estimated  to  range  from  500  to  1,000  tickets.  On  a  typical  weekly 
basis,  the  Vendor  shall  accommodate  a  range  of  2,000  to  6,000  tickets.  The  Vendor 
must  have  the  flexible  capability  to  receive  and  process,  in  a  fully  accurate  and  timely 
manner,  the  above  estimated  ranges  in  addition  to  volumes  of  tickets  that  fluctuate 
lower  or  higher  than  the  ranges  noted  above. 


(4.3.7)  Location 

It  is  expected,  unless  compelling  arguments  are  otherwise  presented,  that  the  Vendor 
receive,  count,  batch  and  reconcile  violation  tickets  at  the  Vendor's  Boston  office, 
which  in  turn  is  expected  to  be  located  close  to  Boston  City  Hall. 
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(4.4)  PARKING  TICKET  DATA  ENTRY 


(4.4.0)  Information  Foundation  and  Zero-Defect  Objective 

The  data  to  be  entered  from  the  parking  ticket  contains  the  essential  and  primary 
information  that  is  utilized  to  create  records  that  serve  as  the  information  foundation  for 
the  PVPMISS.  The  value  of  the  accurate  entry  of  data  and  accounting  for  all  tickets  to 
be  data  entered  cannot  be  overstated.  The  Vendor  must  strive  to  provide  a  zero-defect 
data  entry  operation. 

Although  the  vast  majority  of  parking  tickets  are  issued  electronically,  the  requirements 
listed  herein  should  be  considered  important  and  serve  to  underscore  the  City's 
perspective  of  the  handling  of  such  items. 

The  data  from  the  ticket  is  used,  among  other  things,  to  identify  registrants.  The  entry 
of  the  data  from  the  ticket  must  be  accurate  to  ensure  proper  identification  of  registrants 
and  to  provide  a  computer  record  that  is  utilized  for  customer  service,  adjudication  and 
collection  efforts.  Data  entry  delays  that  impact  processing  timetables  and  data  entry 
errors  that  result  in  the  wrong  person  being  billed,  no  person  being  billed,  incorrect  data 
appearing  on  a  bill  or  a  record,  missing  data  on  a  bill  or  record,  etc.,  must  be  avoided. 
Incorrect  data  entry  would  have  very  negative  operational,  cost,  image  and  integrity 
consequences  for  the  City. 


(4.4.1)  Unique  and  Hybrid  Characteristics 

The  data  entry  function  in  a  parking  ticket  system  is  more  difficult  compared  to  what 
may  be  considered  standard  data  entry  from  a  standard  form  or  document  due  to  the 
manner  and  circumstances  in  which  data  is  captured  and  placed  on  the  source  document 
(the  parking  ticket).  For  example,  the  parking  ticket  is  a  hand  written  document.  It  is 
written  in  a  standing  position  and  in  different  types  of  weather  conditions.  The  ticket 
writer  must  often  think  about  how  to  decode  the  license  plate  type,  color  and  number. 
Further,  the  issuing  agent  does  not  record  data  (issue  a  ticket)  in  a  controlled 
environment  and,  as  an  example  of  the  potential  implications  of  this  reality,  the  ticket 
writer  may  cross  out  an  incorrect  entry  and  note  the  correct  entry  in  the  general  area  or 
down  the  middle  of  the  ticket. 

The  above  factors  should  NOT  be  construed  to  imply  that  the  written  data  from  the 
parking  ticket  document  compromises  the  City's  goal  and  objective  of  zero-defect  data 
entry.  Rather,  it  is  incumbent  upon  the  City  to  stress  to  prospective  Vendors  the  fact 
that  the  time  commitment,  level  of  concentration  and  oversight  commitment  is  more 
consequential  to  the  accurate  entry  of  parking  ticket  data  in  terms  of  a  comparison  to 
more  standard  data  entry  applications. 

The  data  enterer  must  carefully  examine  the  data  on  the  ticket.  For  example,  plate 
types,  similarities  between  street  names,  abbreviations  for  'Other'  vehicle  makes,  etc., 
shall  require  a  careful  and  thorough  examination  of  the  ticket  document.  Also,  what 
may,  at  'first  glance',  appear  to  be  ambiguous  data  is  typically  readily  discernible  upon 
a  more  measured  examination  of  the  written  data  in  question.  Further,  at  times, 
judgment  or  consultation  with  other  personnel  may  have  to  be  employed  relative  to 
printed  as  well  as  written  letters,  numbers,  words,  abbreviations,  etc. 
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(4.4.2)  Information  To  Be  Data  Entered  (Keyed) 


The  Vendor  shall  data  enter  all  the  information  on  the  parking  ticket  except  for  the 
name  of  the  issuing  officer.  Refer  to  the  appendix  to  this  RFP  for  the  current  layout  of 
the  parking  ticket  and  the  data  fields  therein. 

The  Vendor  will  be  required  to  accommodate  a  minimum  of  30  characters  in  the  (street) 
location  field. 

In  addition  to  the  information  on  the  ticket,  the  Vendor  will  be  required  to  enter 
information  from  the  batch  header  cards  and  the  sequence  of  the  ticket  within  the  batch 
unless  this  is  performed  in  an  automated  manner. 


(4.4.3)  Medium  Used  For  Capture  of  Information 

Currently,  the  Vendor  is  required  to  process  the  information  for  transmission  via  IP 
connection  (Daily  File). 


(4.4.4)  Time  Frame  and  Capacity  Requirements 

The  Vendor  shall  data  enter  all  tickets  and  complete  the  Daily  File  and  transmit  within 
one  (1)  working  day  after  receipt  of  the  of  the  copies  of  the  issued  tickets.  (Refer  to 
volume  ranges  set  forth  in  the  preceding  'Parking  Ticket  Pick-Up  Receipt  and  Control' 
section.)  The  original  parking  tickets  shall  be  delivered  to  the  City  for  possible  cross 
reference  of  other  files  such  as  the  Police  Department's  Stolen  Vehicle  File.  The 
originals  shall  be  stored  by  the  City. 


(4.4.5)  Hard  Copy  Report 

The  Vendor  will  produce  on  a  daily  basis  for  its  own  quality  control  and  production 
monitoring  purposes  a  hard  copy  report  reflecting  all  data  entered  from  the  tickets. 


(4.4.6)  Edits  and  Controls 

The  Vendor  must  provide  on-line  and  batch-end  edits  and  the  double  keying  of  critical 
fields  to  ensure  the  validity  of  entered  data  and  identify  ticket  rejects. 

Critical  ticket  fields  to  be  double  keyed  shall  include,  at  a  minimum,  batch  date,  batch 
sequence,  ticket  number,  date  of  issue,  state,  plate  color,  plate  type,  license  plate 
number,  meter  number  and  violation  code. 

Automated  ticket  editing  shall  include,  but  not  be  limited  to: 

-  alpha  and/or  numeric  restrictions/specifications  for  fields  such  as  ticket 
number,  year/date,  state,  time,  meter  numbers,  etc. 

-  numeric  parameters  for  year  and  date  restrictions 

-  issue  date  cannot  be  22  or  greater  days  old 

-  issue  date  cannot  be  greater  than  date  of  data  entry 

-  violation  number  must  pass  check  digit  validation 

-  violation  number  must  be  complete 
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-  issue  date,  plate  number,  plate  state,  plate  color,  plate  type  (PA,  AP,  CP,  OT) 
violation  code  and  location  cannot  be  missing 

-  the  City  of  issue  must  be  Boston 

-  if  a  Massachusetts  registration,  first  character  cannot  be  the  number  zero  (0), 
if  a  Massachusetts  registration,  if  first  character  is  the  letter  'O',  second 
character  cannot  be  the  number  zero  (0) 

-  if  a  Massachusetts  registration,  the  fourth  character  cannot  be  the  letter 
'O'  (except  vanity  plates). 


(4.4.7)  Data  Entry  Specifications 

The  Vendor  is  responsible  for  submitting  and  utilizing  detailed,  thorough  and 
comprehensive  data  entry  specifications  and  procedures. 


(4.4.8)  Hardware  and  Software 

The  Vendor  must  provide  state  of  the  art  hardware  and  software. 


(4.4.9)  Quality  Control 

The  Vendor  must  provide  detailed,  thorough  and  comprehensive  quality  control  over 
the  data  entry  function. 


(4.4.10)  Personnel 

The  Vendor  must  provide  well-trained,  qualified  and  sufficient  staff  to  perform  the  data 
entry  functions. 


(4.4.11)  Reconciliation 

The  Vendor  is  responsible  and  must  account  for  identifying  and  reconciling  any 
differences  in  the  number  of  tickets  delivered  to  the  data  entry  facility  and  the  number 
of  tickets  entered.  The  Vendor  is  responsible  for  ensuring  that  only  tickets  issued  by  the 
City  (and  authorized  agencies)  and  delivered  to  the  Data  Entry  facility  are  actually 
entered. 


(4.4.12)  Unprocessable  Tickets 

Tickets  that  are  determined  to  be  unprocessable  due  to  missing  or  invalid  data  shall  be 
data  entered  to  the  Vendors  system,  to  the  extent  possible  with  the  information 
contained  on  the  ticket,  as  void  /  unprocessable  citations.  Such  tickets  shall  be  batched, 
accounted  and  categorized  separately  from  processable  tickets  by  void  reason.  The 
Vendor's  on-line  PVPMISS  shall  reflect  zero  dollars  due  for  all  such  void  / 
unprocessable  tickets  and  void  reason. 
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(4.4.13)  Reports 


The  Vendor  shall  provide  accurate  and  timely  reports  on  a  daily,  weekly,  monthly  basis. 


(4.4.14)  Oversight  of  a  Subcontractor 

The  Vendor  shall  be  completely  responsible  for  the  Data  Entry  function  from  all 
perspectives  -  whether  performed  directly  by  the  Vendor  staff,  via  a  subcontract  or 
other  arrangement.  This  responsibility  shall  include,  but  not  be  limited  to  oversight, 
quality  control,  compliance  with  contractual  time  requirements,  reconciliation  of 
delivered  and  data  entered  tickets,  and  establishment  of  edits  and  controls. 


(4.4.15)  Location 

The  City  desires,  and  it  is  expected,  that  the  Vendor  locate  its  data  entry  facility  close  to 
City  Hall  and  the  Vendor's  Boston  office. 
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4.5 

UPDATING  TICKETS  TO  ON-LINE  AND  MASTER  FILES 
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(4.5)  UPDATING  TICKETS  TO  ON-LINE  AND  MASTER  FILES 


The  Vendor,  within  one  working  day  of  receiving  the  'Daily  File'  of  newly  data  entered 
tickets,  will  add  this  information  to  the  Master  Violations  File  and  match  the  vehicle 
registrations  appearing  on  the  issued  tickets  against  the  records  in  the  Master  Violations 
File. 

As  part  of  the  process  of  adding  the  new  ticket  data  to  the  Master  Violations  File,  the 
Vendor  is  responsible  for  validating,  editing  and  controlling  the  information  which  was 
data  entered  from  the  ticket.  This  should  include,  but  may  not  be  limited  to,  the 
registration  data. 

If  the  registration  appearing  on  the  newly  entered  ticket  matches  an  existing  record  in 
the  Master  Violation  File,  the  Vendor  will  add  the  ticket  data  to  the  existing  plate 
record. 

If  the  registration  appearing  on  the  newly  entered  ticket  does  not  match  an  existing 
record  in  the  Master  Violation  File,  the  Vendor  will  add  the  ticket  data  to  a  newly 
created  registration  record. 

The  Vendor  will  make  the  new  ticket  data  available  for  on-line  access,  system  usage, 
etc.,  once  it  has  been  added  to  the  Master  Violation  File. 

The  Vendor  will  make  the  new  ticket  data  available  to  the  City  MIS  Department  in  an 
electronic  file  format  once  it  has  been  added  to  the  Master  Violation  File. 


(4.5.1)  Note  Regarding  Excise  Tax 

The  Vendor  will  be  required  to  accept  information  from  the  City  MIS  Department 
regarding  Excise  Tax  debts  owed  to  the  City  of  Boston.  This  information  must  be 
displayed  at  the  registration  level  in  the  Master  Violation  File.  The  format  and  record 
layout  shall  be  specified  by  the  City. 

The  City  will  periodically  notify  the  Vendor  of  Excise  Tax  Bills  which  are  no  longer 
owed  to  the  City,  for  removal  from  the  Master  Violations  File. 
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4.6 

LOCKBOX  PROCESSING  FUNCTIONS 
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(4.6)  LOCKBOX  PROCESSING  FUNCTIONS 


(4.6.0)  Lockbox  Payments  and  Correspondence 

The  Vendor  shall  efficiently  and  effectively  provide  for  the  numerous  services  relating 
to  (a)  the  receipt  and  routing  of  all  lockbox  mail,  (b)  the  processing,  accounting  and 
daily  deposit  of  lockbox  and  mailed  payments,  c)  the  routing  of  parking  ticket  related 
correspondence,  and  d)  the  scanning  of  parking  ticket  related  correspondence  (refer  to 
the  section  of  this  RFP  entitled  'Imaging'  for  a  discussion  relative  to  scanning 
requirements). 


(4.6.1)  Subject  to  Intense  Public  Scrutiny  /  Zero-Defect  Objective 

The  value  of  the  accurate  and  timely  processing  and  accounting  of  lockbox  and  mailed 
payments  and  routing  of  parking  ticket  related  correspondence  cannot  be  overstated.  It 
is  absolutely  essential  that  payments  be  efficiently  and  correctly  processed,  applied, 
deposited  and  updated  on  a  daily  basis  and  that  all  correspondence  received  by  the 
Vendor  be  correctly  segregated,  labeled,  scanned,  as  required,  and  sent  to  the  City  on  a 
daily  basis. 

The  processing  of  lockbox  (and  other)  parking  ticket  payments  is  subject  to  intense 
public  scrutiny.  Therefore,  the  Vendor  must  strive  to  provide  a  one  hundred  percent 
correct,  zero-defect  lockbox  processing  function. 

Misapplied  payments,  unapplied  payments,  delayed  payments  and  incorrectly  sorted, 
scanned  or  delayed  correspondence  would  pose  serious  problems  for  the  City  and  could 
not  be  tolerated.  By  way  of  an  example  and  without  limitation,  a  misapplied  payment 
could  cause  additional  collection  action  including  vehicle  seizure  or  RMV  Non- 
Renewal  action  to  a  violator  who  in  good  faith  sent  a  ticket  payment  to  the  City's 
lockbox.  Such  situations  would  create  intense  violator  complaints  and  result  in  serious 
customer  service  and  public  relations  problems  for  the  City.  Such  problems  would 
adversely  impact  the  integrity  of  parking  enforcement  programs,  in  addition  to  causing 
a  deployment  of  resources  away  from  other  functions  and  responsibilities. 


(4.6.2)  Non-Standard  Characteristics  and  Research  Items 

The  City  views  the  Lockbox  Processing  Function  in  Boston's  parking  ticket  system 
as  a  non-standard  lockbox  function  that  is  more  difficult  compared  to  other 
account-  receivable-type  operations. 

For  example,  payments  must  be  applied  to  specific  transactions  (i.e.,  parking 
violations),  each  with  a  discrete  and  dynamic  dollar  amount  due,  rather  than  being 
generally  applied  to  a  single  account-balance-due.  The  audit  trail  on  the  check 
endorsements  must  always  be  legible.  Also,  the  instances  of  correspondence  with 
returned  statements  is  much  higher  than  in  other  lockbox  operations.  In  addition, 
relatively  complex  payment  processing  procedures  developed  by  the  City  that  reflect 
numerous  payment  processing  scenarios  must  be  adhered  to.  Also,  processing  staff 
must  be  familiar  with  the  various  parking  ticket  dunning  notices. 
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Further,  although  areas  such  as  notice  layout  are  designed  to  facilitate  efficient  and 
effective  lockbox  payment  processing,  processing  staff  will  frequently  be  called  upon  to 
conduct  relatively  complicated  or  involved  file  inquiries  and  investigations  (utilizing  the 
Vendor  provided  PVPMISS)  in  order  to  correctly  process  payments,  particularly 
research  items. 

The  Vendor  shall  expect  to  receive  a  wide  variety  of  notices  and  often-ambiguous 
handwritten  payment  instruction  documents  through  the  lockbox.  Additionally, 
violators  send  payments  for  multiple  tickets,  notices  and  registrations  which  sometimes 
do  not  equal  amounts  due  on  source  documents.  The  Vendor  shall  be  required  to 
conduct  all  required  file  inquiries  and  system  investigations  to  apply  payments  to 
outstanding  violations. 

The  above  factors  should  NOT  be  construed  to  imply  that  the  non-standard  nature  of  the 
City's  parking  ticket  lockbox  function  compromises  the  City's  goal  and  objective  of 
zero-defect  processing.  Rather,  given  this  objective,  it  is  incumbent  upon  the  City  to 
stress  to  prospective  Vendors  the  fact  that  the  time  commitment,  level  of  concentration 
and  oversight  commitment  is  more  consequential  to  the  accurate  processing  of  parking 
ticket  related  mail  in  terms  of  a  comparison  to  more  standard  lock  box  and  payment 
processing  operations. 


(4.6.3)  Staffing  and  Managerial  Oversight 

The  Vendor  shall  provide  extensive,  efficient  and  effective  managerial  and  supervisory 
oversight  of  the  lockbox  processing  function.  Lockbox  staffing  levels  are  to  be 
approved  by  the  City. 

Further,  in  large  part  due  to  the  considerations  set  forth  on  the  preceding  pages, 
proposers  are  advised  that  the  City  requires  a  lockbox  processing  staff  dedicated  to,  and 
one-hundred  percent  focused  upon,  processing  parking  ticket  related  mail  receipts.  This 
general  requirement  is  not  intended  to  prohibit  management  approaches  that  utilize  staff 
rotation,  etc.,  or  approaches  designed  to  optimize  operational  flexibility  and 
effectiveness,  or  to  prohibit  the  subcontracting  of  this  function.  However,  the  City 
desires  and  expects  that  a  relatively  consistent  and  specific  group  of  Vendor  personnel 
be  dedicated  to  Boston  items  during  periods  of  time  in  which  those  items  are  actually 
being  handled  and  processed  at  the  lockbox.  It  is  expected  that  said  periods  of  time  will 
be  considerable.  What  the  City  must  avoid,  notwithstanding  normal  and  expected  levels 
of  turnover,  promotions,  etc.,  is  a  situation  where  the  lockbox  staff  cannot  consistently 
deliver  a  proficiency  and  expertise  with  the  characteristics  (non-standard  or  otherwise) 
of  this  lockbox  function  and  the  specific  requirements  of  the  City  relative  to  this 
function. 
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(4.6.4)  Lockbox  Transaction  Processing  Facility 


It  is  expected,  unless  compelling  arguments  are  otherwise  presented,  that  the  Vendor's 
lockbox  office  and  staff  shall  be  located  at  the  Vendor's  Boston  office,  which  in  turn  is 
expected  to  be  located  close  to  Boston  City  Hall. 

The  lockbox  processing  facility  must  be  in  a  secure  area  with  restricted  access  to 
authorized  Vendor  and  City  staff.  The  processing  facility  must  be  equipped  with 
sufficient  fire  protection  devices.  Physical  access  must  be  further  controlled  to  any  on- 
line processing  devices.  The  Vendor  shall  provide  an  internal  security  system  to  ensure 
that  valuable  City  parking  ticket  payments  and  City  correspondence  are  processed  in  a 
secure  environment. 


(4.6.5)  Payment  Processing  System 

The  Payment  Processing  System  utilized  by  the  Vendor  must  efficiently  and  effectively 
accommodate  the  high  volume  and  unique  nature  of  parking  violation  ticket  payment 
transactions.  The  Vendor's  Payment  Processing  System  shall  provide  the  flexibility  for 
lockbox  payment  processors  to  process  the  following: 

a)  whole  ticket  payments 

b)  partial  ticket  payments 

c)  multiple  whole  ticket  payments 

d)  multiple  partial  ticket  payments 

e)  whole  registration  payments 

f)  multiple  whole  registration  payments 
etc. 


(4.6.6)  Lockbox  Processing  Overview 

The  Vendor  shall  efficiently  and  effectively  provide  for  all  services  relating  to  (1)  the 
receipt  and  routing  of  all  lockbox  mail,  (2)  the  processing,  accounting  and  daily  deposit 
of  lockbox  and  mailed  payments,  (3)  the  routing  of  parking  ticket  related 
correspondence,  and  (4)  the  scanning  of  parking  ticket  related  correspondence. 

In  addition  to  other  requirements  set  forth  in  this  section,  the  following  procedures  and 
requirements  shall  apply  to  the  processing  of  lockbox  related  items: 


a)  The  Vendor  shall  rent  a  post  office  lockbox  (es).  The  contents  of  which  shall,  at 
a  minimum,  be  removed  by  the  Vendor  (via  a  bonded  messenger  or  courier)  at 
the  beginning  of  each  processing  day.  The  courier  shall  deliver  the  contents  of 
the  lockbox  (es)  to  the  Vendor's  lockbox  processing  facility. 

b)  Upon  receipt  and  opening  of  the  lockbox  contents,  the  Vendor  shall  count  and 
separate  the  mail  as  follows: 

-  mail  with  correspondence  only 

-  mail  with  combination  payments  and  correspondence 

-  mail  with  payments  only 
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Note:  At  present,  the  front-end  processing  of  lockbox  items  is  facilitated  via  the 
utilization  of  different  post  office  box  addresses  for  the  receipt  of:  (a)  parking 
ticket  mailers,  (b)  return  envelopes  and,  (c)  returned  mail.  Also,  return 
envelopes  are  color  coded  according  to  OCR-processability.  It  should  be  noted, 
however,  that  the  public  does  not  always  utilize  the  return  envelopes  provided. 

Tickets,  notices  and  other  mail  with  correspondence  but  without  payments  shall 
be  secured  with  minimal  fastening  devices,  initialed  by  the  processing  clerk, 
dated  with  the  postmark  date,  and  notated  as  correspondence  on  the  outside  of 
the  envelope  or  ticket. 

Such  receipts  shall  be  counted,  batched  into  groups  not  to  exceed  25  items  and 
delivered  (via  bonded  messenger  or  courier)  to  the  Office  of  the  Parking  Clerk 
located  at  City  Hall,  within  twenty-four  (24)  hours  following  receipt  by  the 
Vendor  at  the  lockbox. 

Mail  that  represents  combination  payments  and  correspondence  shall  be 
processed  as  follows:  The  Vendor  shall  process  checks  in  accordance  with  the 
City's  payment  processing  procedures  (which  include  procedures  set  forth  in 
paragraphs  'e'  and  'f"  below)  and  forward  copies  of  checks  and  related 
correspondence  to  the  City  in  accordance  with  specifications  provided  by  the 
City. 

Such  receipts  shall  be  counted,  batched  into  groups  not  to  exceed  25  items  and 
delivered  (via  bonded  messenger  or  courier)  to  the  Office  of  the  Parking  Clerk 
located  at  City  Hall,  within  twenty-four  (24)  hours  following  receipt  by  the 
Vendor  at  the  lockbox. 

Items  that  are  scanned  to  the  Correspondence  Imaging  System  shall  be  batched 
into  groups  of  10  items  each,  secured  with  minimal  fastening  devices, 
accompanied  by  a  lockbox  scanning  control  sheet  (see  the  section  of  this  RFP 
entitled  'Imaging'  for  a  discussion  of  scanning  and  scanning  batch  control 
requirements),  and  delivered  (via  bonded  messenger  or  courier)  to  the  Office  of 
the  Parking  Clerk  located  at  City  hall,  within  twenty-four  (24)  hours  following 
receipt  by  the  Vendor  at  the  lockbox. 

Mail  with  payments  only  shall  be  batched  into  groups  not  to  exceed  100 
documents  to  be  dated  and  numbered  consecutively  00-99.  Each  check  shall  be 
dated  and  endorsed  for  deposit  within  twenty-four  (24)  hours  of  receipt  by  the 
Vendor  at  the  lockbox. 

All  payment  information  shall  be  entered  and  verified  with  appropriate  edits  and 
controls  (discussed  in  this  section)  and  batch  totaling,  and  updated,  eighty 
percent  (80%)  of  the  time,  to  the  Master  Violations  File  and  all  subsystems  and 
system  elements  within  twenty-four  (24)  hours  of  receipt  by  the  Vendor  at  the 
lockbox.  All  remaining  payments  shall  be  processed  and  updated  to  the  Master 
Violations  File  and  all  subsystems  and  system  elements  within  forty-eight  (48) 
hours  of  receipt  by  the  Vendor  at  the  lockbox. 
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The  Vendor  shall  process  in  an  automated  manner  all  payments  accompanied  by 
a  City  of  Boston  source  document  bearing  an  optical  character  recognition 
(OCR)  scan-line,  unless  an  'individual'  document  is  damaged  to  an  extent  that 
would  prohibit  such  automated  processing.  At  a  minimum,  said  source 
documents  shall  include  parking  ticket  mailers  and  standard,  i.e.,  non-online, 
dunning  notices.  The  current  OCR  scan-line  is  OCR-type  "A"  character  font. 

Additional  discussions  relating  to  OCR  processing  of  payments  are  included  in 
the  'Parking  Ticket  Dunning  Notice  System  and  Services'  section  of  this  RFP. 

In  addition  to  any  batch  processing,  the  Vendor  shall  also  accommodate  the  on- 
line, real-time  processing  of  mail  and  lockbox  payments.  This  on-line 
processing  shall  allow  vendor  personnel  to  enter  and  record  payments  and 
payment  adjustments  according  to  the  on-line  payment  and  audit  control 
requirements  described  in  the  On-Line  Payment  Processing  System  section  of 
this  RFP. 

The  on-line  payment  processing  system  utilized  by  the  Vendor  shall  provide  the 
flexibility  to  accommodate,  by  way  of  illustration  and  without  limitation,  the 
following  types  of  payment  activities: 

-  Multiple  Violations 

-  Multiple  Registrations 

-  Research  Items 

-  Exception  Items 

The  on-line  payment  processing  system  utilized  by  the  Vendor  shall 
immediately  post  all  payment  transactions  to  the  Master  Violations  File  as  well 
as  all  subsystems  (e.g.,  Boot  and  Tow  System,  Claims  Processing  System, 
Hearing  System,  etc.). 

The  Vendor  shall  provide  a  handling  and  audit  system  for  any  cash  payments 
received  through  the  lockbox.  The  City  may  require  that  all  processing  staff  be 
bonded. 

This  function  must  conform  to  Generally  Accepted  Principles  for  cash  handling, 
accounting  and  control. 

The  Vendor  shall  accommodate  the  application  of  any  range  of  whole  dollar 
amount  payments  to  a  violation,  e.g.,  if  a  partial  payment  of  thirty-five  dollars  is 
remitted  for  a  forty  dollar  fine,  thirty-five  dollars  must  be  applied  and  the  new 
current  amount  due  must  equal  five  dollars  (in  addition  to  any  penalty). 

The  Vendor  shall  record  on  the  database,  and  display  on  the  on-line  inquiry 
system,  the  date  the  payment  was  added/updated  to  the  Master  Violations  File, 
the  location  of  where  the  payment  was  made  (including  the  pay-by-phone 
system),  the  method  of  payment  (e.g.,  cash,  check,  money  order,  credit  card, 
debit  card),  the  type  of  payment  processing  system  (e.g.,  batch  or  on-line),  and 
the  batch  in  which  the  payment  was  processed  (see  item  'e'  above). 
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1)    The  Vendor  shall  indicate  on  each  check  processed  the  violation  numbers  to 
which  payments  are  applied,  the  date  of  payment,  the  amount  applied  to  each 
violation  number,  a  notation  that  the  payment  was  processed  through  the 
lockbox  and  a  notation  of  the  payment  processing  system  (e.g.  batch  or  on-line). 

m)  Post-dated  checks  shall  be  held  by  the  Vendor  for  10  business  days  and 
processed  when  current. 

n)    Checks  shall  be  endorsed  to  the  account  of  the  Parking  Clerk  of  the  City  of 
Boston.  The  total  amount  of  all  checks  processed  each  day  will  be  credited  to  a 
demand  deposit  account  entitled  "Parking  Fine  Account"  under  the  same  terms 
and  conditions  as  would  apply  to  direct  deposits. 

The  Vendor  shall  deliver  and  deposit  all  moneys  to  an  account  at  a  bank  (or 
banks)  designated  by  the  City. 

o)    The  Vendor  shall  be  required  to  transmit,  batched  as  described  above,  ticket 
payment  documents  to  a  microfilm  vendor  approved  by  the  City  where  they  will 
be  microfilmed  for  record  consolidation  and  retrieval  purposes. 

The  Vendor  must  provide  an  efficient  and  effective  computer  indexing  system 
for  the  storage  and  retrieval  of  microfilmed  ticket  payment  documents. 

Original  ticket  payment  microfilm  shall  be  retained  and  stored  by  the  Vendor  in 
a  secure  and  accessible  area  or  location  for  an  indefinite  period  of  time  unless 
instructed  otherwise  by  the  City.  One  copy  of  such  microfilmed  ticket  payment 
documents  must  be  provided  to  the  City  on  a  weekly  basis,  formatted  to  allow 
City  personnel  to  access  documents  on  the  following  microfilm  reader/  printer: 
Cannon  Microscanner  400. 

p)    The  Vendor  will  be  required  to  retain  and  store  original  source  documents 
received  through  the  lockbox  in  a  secure  and  accessible  area  or  location  for  an 
indefinite  period  of  time  unless  instructed  otherwise  by  the  City.  The  Vendor 
must  provide  an  indexing  system  for  the  efficient  and  effective  retrieval  of  such 
documents. 


(4.6.7)  Research  Items 

The  following  are  examples  of  research,  exception  and  non-standard  items  the  Vendor 
may  receive  through  the  lockbox  and  processing  instructions  for  such  items. 

a)    Where  the  Vendor  receives  a  payment  with  a  vehicle  registration  number  but 
without  a  violation  number,  it  shall  be  responsible  for  carrying  out  the  required 
file  inquiries  to  apply  such  payments  to  violations  outstanding  against  the 
vehicle  registration  number. 

If  the  payment  can  be  applied  to  more  than  one  violation,  the  Vendor  shall  first 
make  payment  to  any  tickets  which  are  less  than  twenty-one  (21)  days  old  and 
then  the  residual  amount,  if  any,  shall  be  applied  in  accordance  with  payment 
application  instructions  to  be  provided  by  the  City. 
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b)  Where  the  Vendor  receives  a  payment  amount  that  exceeds  the  amount  due  on 
the  enclosed  violations,  it  shall  conduct  all  required  file  inquiries  to  determine  if 
any  other  violations  are  outstanding  against  the  vehicle  registration  number.  If 
one  or  more  other  violations  are  outstanding,  the  Vendor  shall  apply  the  excess 
payment  amount  in  accordance  with  the  payment  application  instructions  to  be 
provided  by  the  City.  If  the  excess  amount  cannot  be  applied  to  other  violations, 
the  vendor  shall  follow  the  overpayment  instructions  to  be  provided  by  the  City. 

c)  Where  the  Vendor  receives  an  unsigned  check  or  unappliable  payment  (e.g.,  no 
violation  or  registration  ascertainable),  it  shall,  within  three  working  days  of 
receipt  of  any  such  item: 

1)  Address  an  envelope  to  the  originator  or  maker  of  the  check; 

2)  Enclose  the  unsigned  check,  the  associated  correspondence  and  tickets  and  a 
form  letter  to  be  provided  by  the  City  in  sufficient  quantities;  and 

3)  Send  the  addressed  envelope  and  its  enclosures  to  the  maker  or  originator  of 
the  check.  The  Vendor  shall  provide  the  City  with  a  weekly  report  of  all  such 
unprocessable  payments. 

d)  Payments  for  storage  fees,  seizure  fees,  Abandoned  Vehicles  and  Fleet  /  Rental 
Vehicle  Surcharges  shall  be  forwarded  to  the  City  within  twenty-four  (24)  hours 
following  receipt  by  the  Vendor  at  the  lockbox.  Such  payments  are  not  to  be 
processed  through  the  lockbox. 

The  City  shall  provide  the  Vendor  with  appropriate  procedures  (and  forms  if  applicable) 
for  processing  any  other  payments  not  described  herein  or  in  the  Payment  Processing 
Procedures  manual. 


(4.6.8)  Skeletal  Payments 

Skeletal  transaction  capability  is  required  in  order  to  accommodate  the  processing  of 
violation  payments  when  the  violation(s)  in  question  have  not  yet  been  updated  to  the 
system  (i.e.,  the  Master  Violations  File  is  temporarily  void  of  the  violation  in  question). 
All  such  payment  amounts  shall  be  retained  in  this  file  as  a  skeletal  payment. 


The  Vendor  shall  provide  the  capability  to  create  an  on-line  skeletal  record  containing, 
at  a  minimum,  violation  number,  payment  disposition  date  and  amount  paid. 

The  Skeletal  Payment  shall  be  matched  against  and  applied  to  new  violation  records 
created  on  the  Master  Violations  File. 


(4.6.9)  Capacity  Requirements 

Depending  upon  numerous  factors  (such  as  ticket  issuance,  etc.),  it  is  estimated  that  the 
Vendor  shall  typically  provide  the  capability  to  accurately  and  timely  process  between 
4,000  to  7,000  ticket  payments  per  day.  The  Vendor  must  have  the  capability  to  expand 
this  7,000  ticket  payments  per  day  capacity  by  increments  of  500  payments  per  day. 
This  increase  in  capacity  shall  begin  as  soon  as  the  number  of  ticket  payments  received 
by  the  Vendor  exceeds  7,500  per  day  for  two  consecutive  workdays. 
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(4.6.10)  Bounced/Bad  Checks 


Checks  which  are  returned  by  the  maker's  bank  unpaid  will  be  redeposited  once.  If  such 
items  are  returned  again,  the  Vendor  shall  charge  the  Parking  Fine  Account  in  the 
amount  of  the  unpaid  items. 

The  Vendor  must  arrange  for  violations  which  correspond  to  unpaid  checks  to  be 
reactivated  as  unpaid  on  the  Master  Violations  File  and  to  the  status  preceding  the 
application  of  the  unpaid  check. 

At  the  time  that  the  bad  check  payment  is  decremented  from  the  system,  the  Vendor 
shall  assess  a  bad  check  fee  (currently  $25.00  on  a  license  plate  level)  to  the  license 
plate  record. 

A  notation  communicating  the  receipt  of  a  bad  check  must  be  provided  for  at  the  time  a 
payment  is  decremented  from  the  system.  Such  notation  shall  be  displayed  on  the 
license  plate  and  violation  level  on-line  inquiry  system.  This  notation  shall  be  removed 
six  months  after  the  payment  of  the  bad  check  fee. 

The  Vendor  shall  notify  the  maker  of  a  bad  check  of  the  revised  amount  due  in 
accordance  with  the  specifications  set  forth  in  the  'Parking  Ticket  Dunning  Notice 
System  and  Services'  section  of  this  RFP. 

On  a  weekly  basis,  the  Vendor  shall  provide  the  City  with  a  summary  listing  of  all 
returned  checks  which  shall  contain  the  following  information  for  each  returned  check, 
or  for  similar  batches  of  returned  checks: 

the  date  the  payment  was  initially  applied  to  the  Master  Violations  File 
the  date  the  check  was  returned  by  the  maker's  bank  unpaid 
the  date  the  Parking  Violations  Fine  Account  was  adjusted  and  the  violation(s) 
in  question  returned  to  an  unpaid  status  and  the  resulting  bad  check  fee 
assessed 

the  date  the  check  was  forwarded  to  the  maker  by  the  Vendor 

The  Vendor  shall  also  provide  the  City  with  a  weekly  list  of  all  returned  check 
transactions  charged  to  the  Parking  Fine  Account.  The  format  of  this  weekly  list  must 
be  approved  by  the  City. 

(4.6.11)  Comprehensive  Audits  and  Controls 

The  Vendor  shall  provide  efficient,  effective  and  comprehensive  audit  and  control 
procedures  to  ensure  that: 

a)  all  mail  retrieved  at  the  post  office  lock  box  is  delivered  to  the  processing 
facility/location; 

b)  all  mail  is  correctly  sorted  and  batched; 

c)  the  City  receives  all  correspondence  on  a  timely  basis; 

d)  the  entry  of  payment  information  is  accurate; 

e)  all  batched  payments  submitted  to  processing  staff  are  subsequently  processed; 

f)  all  processed  payments  are  correctly  updated  to  the  system; 

g)  payments  posted  to  the  system  and  deposited  in  the  bank  account  reconcile; 

h)  etc. 
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In  addition,  the  Vendor  shall  completely  and  accurately  account  for  any  rejected  (e.g., 
during  batch  update,  etc.)  items,  including  the  subsequent  re-entry  of  such  items. 

Also,  the  Vendor  shall  maintain  effective  security  over  cash,  checks,  and  terminals. 
This  shall  include,  by  way  of  example,  the  timely  depositing  of  any  cash  payments 
received  and  the  control  of  error  correction  capabilities. 

(4.6.12)  Comprehensive  Financial  Management  For  All  Banking  Activity 

The  Vendor  shall  provide  efficient,  effective  and  comprehensive  financial  management 
of  all  banking  activities.  This  shall  include  payments  received  at  City  Hall  and  the  Tow 
Lot  (for  these  payments  the  City  will  also  provide  comprehensive  financial 
management).  City  personnel  will  work  closely  and  'parallel'  with  the  Vendor  to 
provide  this  important  function. 

The  Vendor  will  serve  as  chief  liaison  between  the  City  and  the  respective  banking 
institutions  that  deal  with  the  Parking  Fine  Accounts. 

The  Vendor  shall  completely  reconcile  and  account  for  amounts  paid,  amounts 
posted/applied  to  the  PVPMISS,  and  amounts  deposited. 

Further,  the  Vendor  shall  provide  the  City  with: 

a)  Complete  reconciliation  of  all  bank  statements  on  a  monthly  basis,  no  later  than 
the  third  week  following  the  month  that  is  to  be  reconciled; 

b)  all  pertinent  back-up  documentation  of  each  transaction  listed  on  all  bank 
statements  either  on  a  daily  basis  or  as  they  are  received  from  the  bank  (e.g., 
daily  lockbox  deposit  slip  copies,  all  bounced  check  bank  listings,  any  and  all 
credit/debit  items,  all  wire  transfer  activity,  etc.; 

c)  Copies,  front  and  back,  of  all  bounced  checks  originally  processed  at  City  Hall. 

(4.6.13)  Comprehensive  Activity  Reporting 

The  Vendor  shall  generate  and  provide  various  activity  reports  to  be  utilized  by  the  City 
and  the  Vendor. 

Report  data  may  be  electronically  transmitted  from  the  Vendor  to  the  City  upon 
approval  by  the  City. 

1)  For  the  on-line  lockbox  payment  processing  system,  the  Vendor  shall  generate  a 
daily  payment  activity  report  on  a  real-time  basis.  This  detailed  report  must  include  at  a 
minimum  the  following  information  for  each  individual  payment  transaction: 

a)  registration  state  and  number 

b)  a  notation  to  indicate  the  payment  processing  system  utilized  (e.g.,  batch  or  on- 
line) 

c)  the  violation  number  which  was  paid 

d)  a  notation  to  indicate  the  type  of  transaction 

e)  the  payment  method 

f)  the  dollar  amount  paid 

g)  the  time  of  the  payment 

h)  the  status  of  the  ticket  (notated  if  skeletal) 
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2)  The  Vendor  shall  also  provide,  on  a  daily  basis,  a  report  of  all  items  (payments  and 
correspondence)  received  via  the  lockbox.  This  report  may  be  manually  prepared.  This 
report  shall  include: 

-  Data  relative  to  payments  received  but  not  deposited  for  the  second  day  preceding 

the  reporting  day  (e.g.,  if  the  reporting  day  is  November  21  for  payments 
processed  November  20,  this  report  must  detail  the  processing  of  any  payments 
from  the  second  previous  processing  day,  which  would  be  November  19). 

-  The  total  number  of  items  received  via  the  lockbox  on  the  date  of  the  report  and  any 

items  from  the  previous  day  not  processed  (e.g.,  a  report  dated  November  21 
indicates  total  mail  received  via  the  lockbox  for  that  morning  and  any  mail 
backlog  not  processed  from  the  previous  day,  November  20). 


-    For  the  day  previous  to  the  reporting  day,  payment  processing  information.  This 
report  must  indicate  the  total  dollar  amount  processed  via  each  of  the  Vendor's 
processing  systems  (e.g.,  on-line  and/or  batch). 

This  report  shall  be  prepared  and  signed  by  a  responsible  member  of  the  Vendor's 
Lockbox  Payment  Processing  staff. 

3)  Further,  the  Vendor  shall  provide  on  a  daily  basis  a  report  of  all  payment  processing 
deposit  data.  Summary  data  for  payment  deposits  must  be  provided  for  all  payments 
processed  and  deposited  for  the  reporting  day,  week,  month  and  fiscal  year  to  date. 
This  shall  include  the  dollar  amounts  of  payments  processed  via  the  Vendor's  lockbox 
on-line  and  any  batch  processing  systems  (separately  reported)  and  payments  processed 
and  deposited  by  the  City  via  the  Vendor's  On-line  Payment  Processing  System. 

This  report  shall  also  include  the  dollar  amount  of  any  returned  checks  received  by  the 
Vendor  for  the  reporting  period. 

4)  Further,  on  a  daily  basis  the  Vendor  shall  provide  a  comprehensive  report  of  all 
transactions  updated  to  the  Master  Violations  File.  This  report  shall,  at  a  minimum, 
contain  the  following  information: 

a)  the  number  of  transactions  and  the  dollar  amount  of  all  cash  payments  processed 
by  the  City  via  the  Vendor's  On-Line  Payment  Processing  System 

b)  the  number  of  transactions  and  the  dollar  amount  of  all  check  payments 
processed  by  the  City  via  the  Vendor's  On-Line  Payment  Processing  System 

c)  the  number  of  transactions  and  the  dollar  amount  of  all  money  order  payments 
processed  by  the  City  via  the  Vendor's  On-Line  Payment  Processing  System 

d)  the  number  of  transactions  and  the  dollar  amount  of  all  credit  card  and  debit  card 
payments  processed  by  the  City  via  the  Vendor's  On-Line  Payment  Processing 
System 

e)  the  total  number  of  transactions  and  the  total  dollar  amount  of  all  payments 
processed  by  the  City  via  the  Vendor's  On-Line  Payment  Processing  System 
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f)  the  number  of  transactions  and  the  dollar  amount  of  all  payments  processed  by 
the  Vendor  via  the  lockbox  reported  separately  for  each  processing  system  (on- 
line and/or  batch) 

g)  the  total  number  of  transactions  and  the  total  dollar  amount  of  all  payments 
processed  by  the  Vendor  via  the  lockbox  for  all  processing  systems 

h)  the  number  of  transactions  and  the  dollar  amount  of  all  automatic  system 
overpayment  reapplications  conducted  by  the  Vendor 

i)  the  number  of  transactions  and  the  dollar  amount  of  all  payments  processed  by 
the  City  via  the  Vendor's  Pay  by  Phone  On-Line  Payment  Processing  System 

j)  the  number  of  transactions  and  the  dollar  amount  of  all  payments  processed  by 
the  City  via  the  Vendor's  Pay  by  Web  On-Line  Payment  Processing  System 

k)    the  total  number  of  transactions  and  dollar  amount  of  all  cash  payment 
transactions  updated  to  the  Master  Violations  File 

1)    the  total  number  of  transactions  and  dollar  amount  of  all  check  payment 
transactions  updated  to  the  Master  Violations  File 

m)  the  total  number  of  transactions  and  dollar  amount  of  all  money  order  payment 
transactions  updated  to  the  Master  Violations  File 

n)    the  total  number  of  transactions  and  dollar  amount  of  all  credit  card  and  debit 
card  payment  transactions  updated  to  the  Master  Violations  File 

o)    the  total  number  of  transactions  and  dollar  amount  of  all  pay  by  phone 
transactions  updated  to  the  Master  Violations  File 

p)    the  total  number  of  all  transactions  and  the  total  dollar  amount  of  all  payment 
transactions  updated  to  the  Master  Violations  File 


5)  Further,  on  a  daily  basis  the  Vendor  shall  provide  a  summary  sheet  of  all  deposits  to 
the  Parking  Fine  Account  made  via  the  lockbox.  This  report  shall  include  the  total 
dollar  amount  of  all  payments  processed  by  the  Vendor  via  each  payment  processing 
system  and  the  total  dollar  amount  of  the  entire  deposit.  This  report  shall  also  include  a 
notation  to  indicate  that  all  payments  have  been  microfilmed  by  the  Vendor  in 
accordance  with  instructions  detailed  in  this  section  of  this  RFP.  This  report  shall  be 
signed  and  dated  by  a  responsible  member  of  the  Vendor's  Lockbox  Payment 
Processing  staff. 

6)  The  Vendor  shall  anticipate  minor  and  occasionally  significant  modifications  to 
reports  detailed  in  this  section  of  this  RPF.  The  Vendor  shall  also  anticipate  that  the 
City  may  require  additional  reports  of  transactions  updated  to  the  Master  Violations 
File. 
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4.7 


ON-LINE.  REAL-TIME  'POINT  OF  SALE' 
PAYMENT  PROCESSING  SYSTEM 
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(4.7)  ON-LINE.  REAL-TIME  'POINT  OF  SALE' 
PAYMENT  PROCESSING  SYSTEM 


(4.7.0)  City  Hall  and  Tow  Lot  Payments 

The  Vendor  shall  provide  a  fully  integrated,  On-Line  Real-Time  'Point  of  Sale' 
Payment  Processing  System  which  will  allow  cashiers  at  City  Hall  and  the  City's  Tow 
Lot  facility  to  efficiently  and  effectively  enter  and  record  payments  and  payment 
adjustments  to  the  Master  Violations  File  as  they  are  received  and  to  provide  receipts  of 
transactions  to  the  payer. 

The  payment  system's  hardware  and  software  must  accommodate  the  high  volume  and 
hybrid  nature  of  parking  violation  ticket  payment  transactions.  The  payment  system 
must  accommodate  the  following  payment  methods  and  notate  the  payment  record  and 
Master  Violations  File  of  the  method  of  payment  and  location  of  payment  (e.g.  On-Line 
Payment  System): 

-  cash 

-  personal  check 

-  money  order 

-  credit  card  (Master  Card,  VISA) 

-  debit  card 

-  other  (unique  payment  methods) 


(4.7.1)  System  Features 

The  cashiering  system  shall  accommodate  and  provide,  at  a  minimum,  the  following 
features: 

a)  Cashiers  employed  by  the  City  to  accept  for  payment  (on-line,  real  time): 

-  whole  ticket  payments 

-  partial  ticket  payments 

-  multiple  whole  ticket  payments 

-  multiple  partial  ticket  payments 

-  whole  registration  payments 

-  multiple  whole  registration  payments 

-  partial  fee  payments  (e.g.  boot  fees,  disposal  fees,  trash  fees, 
storage  fees,  tow  fees,  bad  check  fees) 

-  whole  fee  payments 

-  multiple  partial  fee  payments 

-  multiple  whole  fee  payments 

-  abandoned  vehicle  payments 

-  lease  vehicle  surcharge  payments 


83 


b)  The  on-line,  real  time  adjustments  to  keyed  payment  information  to  correct 
cashier  errors. 

c)  The  on-line,  real  time  immediate  posting  of  all  cashier  transactions  to  the  Master 

Violations  File  as  well  as  all  subsystems  (e.g.,  Boot  and  Tow  System,  Claims 
Processing  System,  Hearing  System). 

d)  Ticket  level  and  plate  summary  level  automatic  on-line,  real  time  calculation  of 

the  remaining  amount  due  or  amount  of  overpayment,  in  the  event  of  partial 
payment  or  overpayment.  The  plate  summary  level  amount  due  must  not 
indicate  ticket  level  overpayments  (e.g.,  summary  level  amount  due  cannot  be 
less  than  zero  dollars  [$0]). 

e)  The  automatic  endorsement  of  checks  and  money  orders  and  the 
imprinting  of  registration  state  and  registration  number,  ticket  number,  fee 
and  fee  type,  date  and  amount  paid  on  the  check  or  money  order,  and 
recording  of  credit  card  or  debit  card  payments.  Re-endorsement  capability 
shall  be  provided. 

f)  The  generation  of  a  payment  receipt  showing:  payment  date,  payment  time, 
method  of  payment,  registration  state,  registration  number,  ticket  number, 
amount  due  on  each  ticket,  amount  paid  on  each  ticket,  boot  fee  paid,  tow  fee 
paid,  storage  fee  paid,  bad  check  fee  paid,  total  ticket  amount  due,  total 
penalty  amount  due,  total  fees  due,  total  amount  paid,  and  change  returned  to 
customer.  Receipt  re-print  capability  shall  be  provided. 

g)  The  development,  at  the  City's  discretion,  of  a  feature  which  will  allow  for 
the  automatic  generation,  upon  operator  command,  of  a  'Certified  Registry 
Receipt'  form  which  is  required  by  registrants  in  non-renewal  status  for 
presentation  to  the  RMV.  The  format  of  this  administrative  release  form  is 
determined  by  the  RMV  and  will  likely  include  at  a  minimum  the  following 
information:  registrant  name,  registrant  address,  plate  number,  payment  date. 

h)  Creation  of  a  backup  transaction  record  for  each  ticket  or  other  transaction, 
printable  on  command,  containing  all  data  captured  on  each  on-line 
transaction. 

i)  Acceptance  of  off-line  payments  at  all  cashiering  locations  in  the  event  of 
data  communications  interruption  with  the  capability  to  maintain  all  payment 
data  captured  on  each  on-line  transaction  in  memory  and  update  such  data  to 
the  Master  Violations  File  in  a  batch  mode  within  24  hours  following  such 
data  communications  interruption;  produce  a  journal  record  containing  all 
data  captured  on  each  off-line  transaction;  and  print  a  receipt  containing  all 
data  contained  on  the  off-line  receipt. 

j)  An  integrated  credit/debit  card  system  with  on-line  cashiering.  Capabilities 
include,  but  are  not  limited  to  a  printable  listing  of  each  transaction  by 
operator  ID,  settlement  report,  the  printing  of  two  receipts  (one  for  the  City, 
one  for  the  customer)  batching  and  transmission  of  totals  to  the  City's  bank. 
The  ability  to  void  and  reprint  a  receipt  shall  also  be  provided. 
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(4.7.1.1)  System  Enhancements 


System  enhancements  shall  be  fully  tested  by  the  Vendor  in  a  payment  processing 
environment  identical  in  configuration  to  the  City's  payment  processing  environment. 
Such  enhancements  shall  be  made  available  and  installed  at  City  cashiering  locations 
only  after  being  completely  tested  by  the  Vendor  in  a  manner  acceptable  to  the  City. 


(4.7.2)  Audit.  Reconciliation  and  Activity  Reporting 

1)  The  on-line  payment  system  shall  generate  a  daily  payment  activity  report  on  a  real 
time  basis  to  facilitate  and  properly  control  cashier  closing  procedures  at  the  end  of  each 
cashier  shift.  This  detailed  report  shall  include  at  a  minimum  the  following  information 
for  each  cashier  /  cashier  I.D.,  for  each  individual  payment  transaction: 

a)  registration  state  and  number 

b)  a  notation  to  indicate  that  the  transaction  payment  was  processed  via  the 
on-line  payment  system 

c)  the  violation  number  which  was  paid 

d)  a  notation  to  indicate  the  type  of  transaction  (i.e.  payment,  adjustment) 

e)  the  payment  method  (i.e.  cash,  check,  money  order,  credit  card,  debit  card) 

f)  the  dollar  amount  paid 

g)  the  time  of  the  payment 

h)  the  status  of  the  ticket  (e.g.  noted  if  skeletal) 


2)  This  report  must  also  provide  summary  data  for  each  cashier  /  cashier  I.D.  and 
summary  data  for  all  transactions  for  each  day,  which  must  include  at  a  minimum 
the  following  information: 

a)  The  number  of  tickets  paid  via  each  payment  method  (i.e.  cash,  check, 
money  order,  credit  card,  debit  card,  other) 

b)  total  number  or  tickets  paid  via  all  methods 

c)  the  dollar  amount  of  tickets  paid  via  each  payment  method  (i.e.  cash, 
check,  money  order,  credit  card,  debit  card,  other) 

d)  the  total  dollar  amount  of  all  tickets  paid  via  all  methods 
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e)  the  number  of  boot  fees  paid  via  each  payment  method  (i.e.  cash,  check, 
money  order,  credit  card,  debit  card,  other) 

f)  the  total  number  of  boot  fees  paid  via  all  methods 

g)  the  dollar  amount  of  boot  fees  paid  via  each  payment  method  (i.e.  cash, 
check,  money  order,  credit  card,  debit  card,  other) 

h)  the  total  dollar  amount  of  boot  fees  paid  via  all  payment  methods 

i)  the  number  of  storage  fees  paid  via  each  payment  method  (i.e.  cash, 
check,  money  order,  credit  card,  debit  card,  other) 

j)  the  total  number  of  storage  fees  paid  via  all  methods 

k)  the  dollar  amount  of  storage  fees  paid  via  each  payment  method  (i.e. 
cash,  check,  money  order,  credit  card,  debit  card,  other) 

1)  the  total  dollar  amount  of  storage  fees  paid  via  all  payment  methods 

m)  the  number  of  tow  fees  paid  via  each  payment  method  (i.e.  cash,  check, 
money  order,  credit  card,  debit  card,  other) 

n)  the  total  number  of  tow  fees  paid  via  all  methods 

o)  the  dollar  amount  of  tow  fees  paid  via  each  payment  method  (i.e.  cash, 
check,  money  order,  credit  card,  debit  card,  other) 

p)  the  total  dollar  amount  of  tow  fees  paid  via  all  payment  methods 

q)  the  number  of  bad  check  fees  paid  via  each  payment  method  (i.e.  cash, 
check,  money  order,  credit  card,  debit  card,  other) 

r)  the  total  number  of  bad  check  fees  paid  via  all  methods 

s)  the  dollar  amount  of  bad  check  fees  paid  via  each  payment  method  (i.e. 
cash,  check,  money  order,  credit  card,  debit  card,  other) 

t)  the  total  dollar  amount  of  bad  check  fees  paid  via  all  payment  methods 

u)  the  total  number  of  all  transactions 

v)  the  total  dollar  amount  of  all  transactions 


86 


(C)  Audit  control  facilities  must  also  be  included,  such  as: 

a)  balancing  of  computer  produced  cashiering  report  to  the  log  printed  on 
the  cashiering  terminal 


b)  password  sign-on,  by  operator 


c)  cash-out  by  operator 


d)  segregation  of  cash,  check,  money  order,  credit  card  and  debit  card 
receipts,  and  cash-out:  totals 


e)  operator  I.D.  retained  in  transactions 


f)  access  for  supervisor  to  view  all  operator  transactions 


(4.7.3)  Vendor  Responsibility  in  the  Event  of  Down  Time 

The  Vendor  shall  be  responsible  for  updating  the  Master  Violations  File  (through  the 
On-Line,  Real  Time  Payment  Processing  System  and  on  the  date  of  receipt)  with  all 
payments  received  during  the  hours  of  8:00  A.M.  through  7:30  P.M.  by  the  cashiers  at 
City  Hall  and  with  all  payments  received  during  the  hours  of  5:00  A.M.  on  a  previous 
day  through  3:00  A.M.  on  the  current  day  (22  hours)  by  cashiers  at  the  Tow  Lot  when 
the  downtime  periods  of  the  on-line  payment  system  aggregate  to  more  than  sixty  (60) 
minutes  per  day.  The  Vendor  shall  be  responsible  for  providing  all  the  required 
controls,  reports,  procedures  and  documentation  required  to  ensure  that  all  City  Hall  and 
Tow  Lot  payments  processed  by  the  Vendor  can  be  reconciled  with  payments  processed 
and  monies  received  by  City  cashiers. 


(4.7.4)  Equipment 

The  cashiering  system  shall  consist  of  eight  (8)  workstations.  Four  (4)  of  the  on-line 
cashiering  stations  will  be  located  at  City  Hall,  two  (2)  will  be  located  at  the 
Transportation  Department's  200  Frontage  Road  tow  site  and  three  (3)  fully  configured 
back-up  workstations  will  be  maintained  by  the  Vendor  at  the  Vendor's  Boston  office. 
(Print  capabilities  for  'Certified  Registry  Receipts'  may  only  be  required  for  the  City 
Hall  workstations.  Depending  upon  the  Vendor's  approach  to  this  print  function,  two 
printers  may  be  required.) 

The  Vendor  shall  be  responsible  for  all  cashiering  system  related  supplies  including  one 
and  two-part  receipt  paper  specified  by  the  City. 
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Additional  cashiering  system  equipment  shall  be  calculated  as  follows: 

for  each  250,000  (two  hundred  and  fifty  thousand)  tickets  issued  in  excess  of 
2,000,000  (two  million),  the  Vendor  must  provide,  at  the  sole  determination 
of  the  City,  one  (1)  cashiering  terminal  workstation  and  one  receipt  printer. 


The  Vendor  shall  also  provide  installation,  on-site  maintenance  and  technical  support 
for  any  additional  equipment,  as  detailed  above.  The  City  shall  provide  the  Vendor 
with  a  plan  of  the  locations  of  where  such  devices  shall  be  installed. 

The  City  may  require  the  Vendor  to  maintain  at  a  location  close  to  City  Hall,  redundant 
system  capability  as  an  additional  means  of  providing  technical  support. 


(4.7.5)  Skeletal  Payments  and  Dispositions 

All  payment  amounts  and  other  dispositions  which  cannot  be  applied  to  a  violation 
number  contained  in  the  Master  Violations  File  because  the  database  is  temporarily  void 
of  the  violation  record  shall  be  retained  in  that  file  as  a  Skeletal  Payment  or  Disposition 
Transaction.  Skeletal  transaction  capability  is  required  in  order  to  accommodate  the 
processing  of  violation  transactions  when  the  violation(s)  in  question  has  not  yet  been 
updated  to  the  system.  The  Vendor  shall  provide  the  capability  to  create  an  on-line,  real 
time  skeletal  record  containing,  at  a  minimum,  violation  number  and  payment 
disposition  date.  The  skeletal  transaction  shall  be  matched  against  and  applied  to  new 
violation  records  created  on  the  Master  Violations  File. 


(4.7.6)  Boot  and  Tow  (Seizure)  System  Interface:  Automatic  Release 

The  On-Line  Payment  System  shall  provide  for  the  on-line,  real-time  and  automatic 
authorization  to  release  a  booted  or  towed  vehicle. 

This  authorization  shall  be  automatically  generated  and  triggered  upon:  a)  data  input  of 
a  boot/tow  payment,  and  b)  data  input  of  an  Administrative  Release  transaction. 

The  automatic  release  shall  be  initiated  without  requiring  the  data  input  person  to  input 
any  special  release  commands.  For  example,  payment  of  the  boot/tow  fee  could 
automatically  initiate  the  'release'  action. 


(4.7.7)  Bar  Code  Scanning  of  Parking  Tickets 

The  Vendor  shall  provide  the  capability  to  utilize  bar  code  technology  for  the  payment 
of  parking  tickets  and  update  of  parking  ticket  data  to  the  Vendor's  core  parking 
violation  system.  Such  capability  shall  be  fully  integrated  with  the  Vendor's  point  of 
sale  on-line  payment  processing  system,  at  all  City  payment  processing  locations. 
The  Vendor  shall  provide  all  equipment  and  communication  devices  necessary  for  the 
successful  operation  of  such  application.  This  technology  and  function  shall  also  be 
incorporated  into  kiosk  type  applications.  This  technology  will  also  be  used  for 
inventory  of  impounded  vehicles  at  the  impound  lot(s)  for  the  purpose  of  reconciling 
towing  and  releasing  of  vehicles.  This  technology  shall  also  be  incorporated  into  the 
Resident  Parking  Permit  System.  Please  refer  to  the  section  of  this  RFP  entitled 
"Resident  Parking  Permit  System"  for  a  detailed  discussion  of  this  requirement. 
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(4.7.8)  Boot  and  Tow  (Seizure)  Auto-Release  Audit  Report 

The  Vendor  shall  provide  a  report  of  all  released  towed  and  booted  vehicles  on  a 
weekly  and  monthly  basis.  This  report  shall  contain  at  a  minimum  the  following 
information  for  each  tow  transaction: 

k)  system  generated  release  number 

k)  time  of  tow/boot  (military  time) 

k)  license  plate  number  and  state 

k)  identification  number  of  clerk  who  entered  release 

k)  transaction  type  (i.e.,  boot,  violation  tow  or  seizure  tow) 

f)  the  number  of  tickets  paid 

g)  the  dollar  amount  of  the  tickets  paid 

k)  the  dollar  amount  of  the  seizure  or  tow  fee  paid 
k)  the  dollar  amount  of  storage  fees  paid 
j)  the  total  dollar  amount  collected  per  plate 

k)  summary  totals  for  items  f)  through  j)  above  for  the  reporting  period 

Refer  to  the  section  of  this  RFP  entitled  "Boot  and  Tow  (Seizure)  System"  for  a  further 
discussion  of  Boot  and  Tow  (Seizure)  System  interface  requirements. 


(4.7.9)  Pay  by  Web  Application 

The  Vendor  will  be  required  to  provide  the  Parking  Clerk  with  a  completely  developed 
Pay  by  Web  system  including  application  software,  support  and  maintenance;  financial 
transactions  and  relationships  with  banks,  the  City,  the  credit  card  companies  and  other 
involved  parties  including  clearinghouses  that  provide  real-time  authorizations;  and 
operational,  audit,  reporting  and  reconciliation  functions  related  to  this  activity,  also  at 
its  cost.  The  Vendor  shall  also  be  "Level  1  Payment  Card  Industry"  (PCI)  compliant. 
The  Vendor  shall  conform  to  such  data  security  standards  to  which  Visa  and 
MasterCard  subscribe.  As  such,  the  Vendor  shall  satisfy  Cardholder  Information 
Security  Program  (CISP)  protocol  for  Visa  and  Standard  Data  Protection  (SDP)  for 
MasterCard.  All  Pay  by  Web  transactions  and  transfer  of  funds  to  City  designated  bank 
accounts  must  be  confirmed  within  24  hours.  The  Vendor's  staff  must  reconcile  all  Pay 
by  Web  transactions  and  transferred  amounts  and  resolve  any  discrepancies. 

The  City  will  be  responsible  for  paying  all  credit  card  charges  and  related  authorization 
and  banking  charges  associated  with  the  Pay  by  Web  application.  The  Vendor  will  be 
required  to  provide  access  to  the  Pay  by  Web  application  via  the  City  of  Boston's 
website  (www.cityofboston. gov) . 
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(4.7.10)  Point  of  Sale  Kiosk  Stations 


The  Vendor  will  be  required  to  provide  the  City  with  a  minimum  of  three  (3) 
completely  developed  kiosk  stations.  This  shall  include  application  software,  support 
and  maintenance;  financial  transactions  and  relationships  with  banks,  the  City,  the 
credit  card  companies  and  other  involved  parties,  including  clearinghouses  that  provide 
real-time  authorizations;  and  operational,  audit ,  reporting  and  reconciliation  functions 
related  to  this  activity,  also  at  its  cost.  The  Vendor  shall  also  be  "Level  1  Payment  Card 
Industry"  (PCI)  compliant.  The  Vendor  shall  conform  to  such  data  security  standards  to 
which  Visa  and  MasterCard  subscribe.  As  such,  the  Vendor  shall  satisfy  cardholder 
Information  Security  Program  (CISP)  protocol  for  Visa  and  Standard  Data  Protection 
(SDP)  for  MasterCard.  All  transactions  and  transfer  of  funds  to  City  designated  bank 
accounts  must  be  confirmed  within  24  hours. 

The  Kiosk  stations  shall  be  capable  of  providing  ATM,  bill  payments  functions,  and 
communicate  with  the  Vendor's  Master  Violations  File  through  the  On-line,  Real  Time 
Payment  Processing  System  for  the  payment  of  and  releasing  of  motor  vehicles  at  sites 
to  be  determined  by  the  City.  After  Payments  of  funds,  such  system  shall  generate  and 
communicate  with  the  PVPMISS  sufficient  information  to  produce  receipts,  releases 
and  electronic  data  for  processing  the  release  of  vehicles. 

The  Units  shall  utilize  the  barcode  on  the  parking  ticket,  notice,  or  other  document 
when  available.  Cash,  check  or  credit/debit  card  payments  shall  be  accepted  at  the 
kiosk  and  shall  be  credited  to  the  recipient's  account,  on-line,  real-time. 

The  Units  shall  generate  bar-coded  receipts  that  can  be  presented  at  the  Tow  Lot  for 
releasing  of  motor  vehicles  and  automated  update  of  status  in  the  Parking  Management 
System. 

The  Vendor's  Kiosk  shall  have  the  capability  to  scan  and  retain  a  copy  of  certain 
information  contained  on  a  driver's  license,  state  issued  ID,  or  other  document,  and 
match  such  information  to  certain  information  on  the  credit  card  presented  at  the  POS 
system  at  the  Kiosk  or  provide  other  similar  authentication  and  security  functions  to 
satisfy  the  City's  security  requirements. 
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4.8 


REQUIRED  SCREEN  DATA  FOR  GENERAL  AND  UNIVERSAL 
INQUIRY  AND  CUSTOMER  SERVICE  FUNCTIONS 
TGENERAL  INQUIRY  SCREENS! 
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(4.8)  REQUIRED  SCREEN  DATA  FOR  GENERAL  AND  UNIVERSAL 
INQUIRY  AND  CUSTOMER  SERVICE  FUNCTIONS 


fGENERAL  INQUIRY  SCREENS! 


(4.8.0)  Detailed.  Comprehensive.  Integrated  and  Consolidated  Data  and  Information 
and  Note  to  Prospective  Vendors 

In  addition  to  providing  specialized  access  screens  for  particular  tasks  and  systems  set 
forth  in  this  RFP,  (such  as  On-Line  Payment  Processing,  Claims  Processing,  Multi- 
Owner  Program,  Boot  and  Tow,  Meter  Management  and  Sign  Management),  the 
Vendor  shall  provide  detailed  and  comprehensive  on-line  inquiry  screens  to  efficiently 
and  effectively  support  numerous  general  and  universal  inquiry  and  customer  service 
functions.  In  this  section  the  City  provides  a  detailed  description  of  its  requirements 
and  needs  as  they  relate  to  general  inquiry  screens.  These  screens  are  utilized  for 
numerous  and  vital  tasks  and  are  a  powerful  tool  for  the  efficient  and  effective  handling 
of  customer  service  inquiries  and  disputes  and  the  adjudication  and  collection  of 
parking  tickets. 

The  Vendor  shall  provide  general  inquiry  screens  containing  an  integrated  collection  of 
data  and  information  from  all  systems  and  system  elements  defined  and  specified  in  the 
Scope  of  Services  of  the  Request  For  Proposal,  i.e.,  Noticing,  Claims  Processing, 
Abandoned  Vehicles,  Boot  and  Tow,  Registry  of  Motor  Vehicle  Interface,  Meter 
Management,  etc.  It  is  very  important  that  said  detailed,  comprehensive  and  integrated 
data  be  consolidated  so  as  to  optimize  inquiry  and  scrolling  efficiency  and 
effectiveness.  The  level  of  data  consolidation  described  in  this  section  shall  represent 
general  minimal  requirements. 

Prospective  Vendors  shall  note  that  certain  data  elements  relating  to  general  inquiry 
screens  are  also  described  in  different  sections  of  this  RFP  and  that  those,  and  other, 
data  elements  are  described  in  this  section  in  terms  of  overall  content  and  configuration 
of  general  inquiry  screen  (and  printed)  output. 

Prospective  Vendors  shall  be  advised  that  given  the  large  amounts  and  varying  types  of 
data  required,  the  City  recognizes  that  alternate  screen  data  formats  may  be  acceptable 
under  certain  conditions.  An  examination  of  this  section  reveals  certain  generic 
requirements  such  as:  summary  plate  and  ticket  information,  detailed  plate  information, 
detailed  ticket  information,  correspondence  detail  for  all  tickets,  notice  detail  for  all 
tickets,  RMV  ownership  information,  RMV  non-renewal  information,  batch  update 
detail,  etc.  Prospective  Vendors  proposing  substantially  alternative  general  inquiry 
screens  shall  substantially  satisfy  these  generic  requirements  and  the  provision  of 
information  for  specific  functions,  as  reflected  in  the  City's  screen  data  needs,  in  terms 
of  user-friendliness,  data  relationship,  completeness,  comprehensiveness,  detail, 
integration  and  consolidation.  For  example,  it  is  acceptable  for  a  Prospective  Vendor  to 
exceed  the  City's  minimum  requirements  in  terms  of  consolidation  of  data  so  long  as  the 
output  screen  is  user-friendly  and  satisfies  generic  requirements  for  specific  functions. 
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(4.8.1)  User-Friendly  Lay-Out  and  Scrolling 


The  general  inquiry  screen  lay-outs  must  be  user-friendly. 

Also,  access  between  screens  must  be  operationally  efficient  and  effective  and  user- 
friendly.  For  example,  scrolling  between  screens  for  the  same  license  plate  or  ticket 
record  shall  be  direct  (via  the  screen  number,  for  example)  and  sequential  (via  a  move 
'left'  or  'right'  one  screen,  for  example).  Also,  for  example,  any  sub-screens  shall  be 
directly  accessible  from  screens  of  primary  interest  and  exit  from  any  sub-screens  shall 
provide  for  a  'direct'  exit. 

Further,  ticket  level  access  between  the  general  inquiry  screens  and  other  system 
element  screens  (such  as  Meter  Management,  Correspondence  Processing,  Hearing 
Administration,  etc.)  shall  be  efficient  and  effective. 


(4.8.2)  General  Inquiry  Screens  Main  Access  Menu 

The  general  inquiry  screens  provided  by  the  Vendor  shall,  at  a  minimum,  be  accessible 
by:  (1)  State  Plate  Number,  (2)  Parking  Violation  Number,  (3)  Abandoned  Vehicle 
Violation  Number  and,  when  supplied  by  the  MA  and  out-of-state  Registry  of  Motor 
Vehicles,  (4)  Driver's  License  Number  and  (5)  Name  (for  all  non-archived  violation 
information  for  violations  issued  after  June  30,  2006). 

These  access  methods  shall  be  user-friendly,  efficient  and  effective  and  shall  be 
available  from  a  single  general  inquiry  main  access  menu  screen. 

With  regard  to  'Name'  access,  the  Vendor  shall,  at  a  minimum,  provide  for  access  by:  (i) 
Last  Name,  and  in  order  to  minimize  search/inquiry  time,  shall  also  provide  access  by 
(ii)  First  Name  or  Initial,  (hi)  'State',  e.g.,  'MA,  etc.,  of  the  person/entity's  registration, 
and  (iv)  utilization  of  a  zip  code  for  MA  registrants,  and  by  (v)  'Case  Number'  [refer  to 
Section  4.9.5.3,  'Case  Number  for  Non-Dismissals']  Also,  response  time  for  name 
access  must  be  minimized. 

Further,  on-line  access  via  'Name'  and  'Driver's  License  Number'  shall  accommodate 
record  'collateralization'  functionality.  In  other  words,  all  parking  ticket  related 
registration  records  and  all  abandoned  vehicle  records  assigned  to  the  same  entity  (as 
determined  by  the  shared  exact  name  or  driver's  license  number)  shall  be  automatically 
retrieved/combined  in  a  manner  that  provides  for:  (a)  summary  viewing  of  a  list  of  said 
records,  and  (b)  the  efficient  and  effective  (scrolling  or  other)  access  to  each  individual 
record. 
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(4.8.3)  Primary  Inquiry  Screen  (License  Plate  Screen) 

The  Primary  Inquiry  screen  shall,  at  a  minimum,  contain  the  following  information  for 
each  license  plate  record: 

1)  The  date  and  time  of  inquiry  and  page  notation; 

2)  The  state  plate,  registration  number  and  plate  type; 

3)  The  original  effective  date  of  the  registration  and  the  source  of  this  data; 

4)  The  name  and  address  of  the  registrant,  including  nine  digit  zip  code; 

5)  The  total  number  of  unpaid  violations  and  the  amount  due  for  those 
violations; 

6)  The  total  number  of  seizure  eligible  violations  and  the  amount  due  for  those 
violations; 

7)  The  total  number  of  violations  in  a  Massachusetts  RMV  non-renewal  status 
and  the  amount  due  for  those  violations; 

8)  A  notation  to  indicate  that  violations  previously  issued  to  the  plate  have  been 
archived  or  combined; 

9)  A  notation  to  indicate  if  a  check  payment  for  tickets  issued  to  this  plate 
previously  bounced; 

10)  A  notation  to  indicate  the  status  of  the  plate  if,  for  example,  in  a  seizure, 
seizure  eligible,  seizure  escape,  towed,  pending  tow  release,  or  auctioned 
status; 

11)  The  total  amount  due  for  the  registration  along  with  separate  listing  for  (each 
of)  fines,  penalties  and  fees; 

12)  A  notation  to  indicate  'Nixie'  status; 

13)  For  each  violation,  for  a  desired  minimum  of  ten  (10)  tickets  per  screen,  the 
following  data: 

a.  Ticket  number 

b.  Date  of  issuance 

c.  Time  of  issuance 

d.  Make  of  vehicle  as  recorded  on  ticket 

e.  Violation  disposition  notation  (e.g.,  swapped  from  a  previous 
registration,  dismissed,  on  hold,  hold  removed,  etc.),  if  any 
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f.  Specific  violation  for  which  ticket  was  issued 

g.  Location  of  violation 

h.  Fine  amount  for  which  ticket  was  issued 

i.  Penalty  amount(s) 

j.     Total  amount  due  for  the  violation. 

14)  A  notation  to  indicate  additional  violations  contained  on  another  screen; 

15)  Instructions  for  performing  additional  functions. 

Further,  the  Vendor  shall  accommodate  access  from  the  Primary  Inquiry  Screen  to 
additional  license  plate  records  associated  with  the  driver's  license  number  of  the  owner 
of  each  license  plate  record  in  a  manner  that  provides  for:  (a)  summary  viewing  of  a  list 
of  said  records,  and  (b)  the  efficient  and  effective  (scrolling  or  other)  access  to  each 
individual  record.  Access  to  such  additional  license  plate  records  shall  be 
accommodated  in  an  operationally  convenient,  efficient  and  effective  manner. 


(4.8.4)  Additional  License  Plate  Level  Data  Screen: 

The  Additional  License  Plate  Level  Data  Screen  shall,  at  a  minimum,  be  accessible 
from  the  Primary  Inquiry  Screen  and  contain  the  following  information  for  each  license 
plate  record: 


1)  The  date  and  time  of  inquiry; 

2)  The  state  plate,  registration  number  and  plate  type; 

3)  The  original  effective  date  of  the  registration  and  the  source  of  this  data; 

4)  The  registrant's  drivers  license  number  and  date  of  birth; 

5)  The  Multi-owner  number,  if  any  and  the  date  that  the  Multi-owner  term 
expires; 

6)  The  last  name  of  the  registrant; 

7)  The  date,  the  name  and  address  request  was  sent  to  the  RMV,  the  date  the 
request  was  processed  by  the  RMV,  and  the  source  of  the  most  recent  address 
update; 
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The  vehicle  identification  number  (this  data  is  currently  not  captured, 
however,  the  Vendor  must  provide  a  field  to  display  this  data  at  the  plate 
detail  level); 

The  identification  number  of  the  RMV  hold  request; 

The  total  number  of  violations  in  a  Massachusetts  RMV  non-renewal  status 
and  the  amount  due  for  those  violations; 

The  current  non-renewal  status  and  most  recent  date  of  the  hold  request; 
The  date(s)  of  which  the  plate  was  seized; 

The  total  number  of  violations  in  a  seizure  eligible  status  and  the  amount  due 
for  those  violations; 

The  current  status  of  the  license  plate  (e.g.,  seized,  seizure  eligible,  seizure 
escaped,  towed  or  auctioned); 

The  total  amount  due  for  the  license  plate; 

The  number  of  times  mailed  notices  have  been  returned  by  the  Post  Office 
and  the  status  and  date  of  the  most  recent  return; 

The  type  of  the  most  recent  correspondence  sent  to  the  registrant,  the  clerk 
who  processed  it  and  the  date  and  time  it  was  mailed; 

The  type  and  amount  of  fee  assessed  as  well  as  the  date  of  assessment; 

The  date  and  amount  of  fee  payment; 

A  notation  to  indicate  additional  fee  data  which  can  be  viewed  on  another 
inquiry  screen; 

21)  The  date  for  which  the  next  system  generated  action,  e.g.,  ILS  Notice,  is 
scheduled; 

22)  The  most  recent  type  of  notice  sent  to  the  registrant; 

23)  The  status  of  the  plate  transfer; 

24)  Instructions  for  performing  additional  functions. 

Further,  the  Vendor  shall  accommodate  access  from  the  Additional  License  Plate  Level 
Data  Screen  to  additional  license  plate  records  associated  with  the  driver's  license 
number  of  the  owner  of  each  license  plate  record  in  a  manner  that  provides  for:  (a) 
summary  viewing  of  a  list  of  said  records,  and  (b)  the  efficient  and  effective  (scrolling 
or  other)  access  to  each  individual  record.  Access  to  such  additional  license  plate 
records  shall  be  accommodated  in  an  operationally  convenient,  efficient  and  effective 
manner. 
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(4.8.5)  Ticket  Level  Data  Screen: 


For  any  specific  ticket  the  Ticket  Level  Data  Screen  shall,  at  a  minimum,  be  accessible 
from  all  plate  level  inquiry  screens  that  contain  as  output  that  specific  ticket.  The 
Ticket  Level  Data  Screen  shall,  at  a  minimum,  contain  the  following  information  for 
each  violation: 


1)  Date  and  time  of  inquiry; 

2)  State  plate,  registration  number,  plate  color  and  plate  type; 

3)  Effective  date  of  registration; 

4)  The  name  and  address  of  the  registrant; 

5)  Ticket  number; 

6)  Total  amount  due  for  ticket; 

7)  Violation  code  and  description  of  violation; 

8)  Issue  date  of  violation; 

9)  Time  of  issuance  of  violation; 

10)  Location  of  violation; 

11)  Vehicle  make,  color  and  style  of  vehicle  as  recorded  on  the  violation; 

12)  Meter  number,  if  any; 

13)  The  Office  of  the  Parking  Clerk  Correspondence  Request  Number,  if 
applicable; 

14)  The  following  issuing  officer  data: 

a.  badge  number 

b.  agency  number 

c.  division  number 

d.  route  number; 

15)  The  amount  of  the  initial  fine  and  the  amounts  and  listing  of  up  to  two 
penalties  assessed  to  the  violation; 

16)  The  dates  and  types,  for  at  least  five  notices,  of  notices  sent  to  the  registrant 
for  the  violation.  Notice  information  for  notices  exceeding  a  fifth  notice  may 
be  viewed  from  another  screen,  providing  that  a  notation  of  said  additional 
information  is  provided; 
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17)  The  date  the  ticket  was  added  to  the  Master  Violations  File  as  well  as  the  date 
the  ticket  was  keypunched; 

18)  The  exact  position  of  the  ticket  in  the  microfilm  ticket  batch; 

19)  Data  provided  by  the  RMV  for  the  registration  of  the  vehicle  ticketed: 

a.  the  make  of  vehicle  as  recorded  by  the  RMV 

b.  the  color  of  the  license  plate  characters 

c.  the  date  the  information  request  was  received  by  the  RMV. 

d.  a  notation  to  indicate  if  mailed  notices  sent  to  the  registrant  have  been 
returned  by  the  Post  Office  (Nixie  Notation) 

e.  the  date  the  ticket  was  accepted  by  the  RMV  for  license  plate  or  drivers 
license  non-renewal  and  the  current  status  of  the  request 

20)  The  date  and  type  of  hearing  scheduled  for  the  ticket; 

21)  The  date  and  type  of  action  temporarily  holding  the  violation  in  abeyance; 

22)  The  date  and  type  of  the  most  recent  correspondence  sent  to  the  registrant  for 
the  violation; 

23)  The  date  of  payment  of  the  violation,  the  method  of  payment,  amount  paid 
and  a  notation  to  indicate  additional  payment  information  which  can  be 
viewed  on  another  inquiry  screen  if  only  'last  payment'  is  captured; 

24)  Instructions  for  performing  additional  functions. 


(4.8.6)  Additional  Ticket  Level  Payment  &  Notice  Data  Screen:(Ticket  History  Screen) 

This  screen  may  not  be  required  if  the  'Ticket  Level  Data  Screen'  can  accommodate  (in 
terms  of  space)  the  notice,  appeal  and  payment  information  in  question.  However  due 
to  possible  multiple  payment,  etc.,  transactions  for  a  particular  ticket,  for  example,  the 
City  recognizes  that  provision  of  complete  data  on  the  'Ticket  Level  Data  Screen'  may 
be  problematic. 
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Therefore,  for  any  particular  ticket,  in  addition  to  summary  level  registration  and  ticket 
data  (which  shall  include  State  Plate,  Registration  Number,  Plate  Type,  Ticket  Number, 
Violation  Description  and  Code  Number,  Issue  Date  of  Violation,  Time  of  Issuance, 
Location  of  Violation,  and  Meter  number)  and  instructions  for  performing  additional 
functions,  the  Ticket  History  Screen  should  contain,  at  a  minimum,  the  following 
information  categories  and  detail  data  so  that  all  transactions  for  a  particular  ticket  are 
reflected  (and  listed  in  chronological  order  from  most  recent  to  first  transaction): 

a)  Listing  of  amount,  method,  dates  (process  and  application),  and  location  of 
each  payment  transaction  (including  bounce  checks  and  refunds),  with  the 
most  recent  separately  denoted; 

b)  The  system  generated  and  actual  mail  dates  (if  different)  and  type  of  each 
notice  sent  for  the  violation; 

c)  Appeal,  suspension  and  hearing  data  including  dates  and  claims  processing 
code; 

d)  Fine  and  penalty  dismissal  data  including  dates  and  claims  processing  codes. 

The  City  desires  to  minimize  scrolling  activity  and  to  maximize  the  efficiency  and 
effectiveness  of  ticket  history  inquiry.  Therefore,  the  ticket  history  function  shall 
preferably  accommodate  a  minimum  of  ten  total  transactions  per-screen-page  prior  to  a 
need  to  scroll  to/access  a  second,  etc.,  same-screen  'page'. 

It  should  be  noted  that  the  provision  of  this  screen  is  required  in  addition  to  the  'Ticket 
Level  Data  Screen',  unless  the  latter  can  accommodate  the  integrated  and  chronological 
listing  of  various  transaction  types.  The  Ticket  History  Screen  would  most  efficiently 
and  effectively  be  accessed  directly  from  the  Ticket  Level  Data  Screen  (via  some  type 
of  visual  'prompt',  if  necessary). 


(4.8.7)  Plate  Level  Penalty  Detail  Screen 

The  Plate  Level  Penalty  Detail  screen  shall  contain  information  about  the  fines  and 
corresponding  penalties  (late  penalty  and  RMV  penalty)  for  each  ticket  as  well  as 
payment  data. 

The  Plate  Level  Penalty  Detail  Screen  should  accommodate  a  minimum  of  ten  violation 
records  (per  plate)  per  screen  prior  to  scrolling  to  'page  2',  etc.,  for  a  particular  plate. 

Summary  level  registration  data,  instructions  for  performing  additional  functions  and  (if 
applicable)  a  notation  to  indicate  additional  information  contained  on  more  screens, 
must  also  be  provided. 
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(4.8.8)  Plate  Level  Notice  Detail  Screen 


The  Plate  Level  Notice  Detail  Screen  shall  contain  detailed  information  regarding  the 
dates  and  corresponding  types  of  notices  sent  for  each  ticket. 

The  Plate  Level  Notice  Detail  Screen  should  accommodate  a  minimum  of  ten  violation 
records  (per  plate)  per  screen  prior  to  scrolling  to  'page  2',  etc.,  for  a  particular  plate. 

Also,  minimum  of  five  notices  per  ticket  per  screen  should  be  provided.  Further, 
summary  level  registration  data,  instructions  for  performing  additional  functions  and  (if 
applicable)  a  notation  to  indicate  additional  information  contained  on  more  screens, 
shall  also  be  provided. 


(4.8.9)  Registry  Data  Detail  Screen 

The  Registry  Data  Detail  Screen  shall  contain  information  regarding  the  vehicle 
registration  for  each  ticket-  initiated  request. 

The  Registry  Data  Detail  Screen  should  accommodate  a  minimum  of  ten  violation 
records  (per  plate)  per  screen  prior  to  scrolling  to  'page  2',  etc.,  for  a  particular  plate. 

For  each  violation  record,  in  addition  to  containing  summary  level  registration  data, 
instructions  for  performing  additional  functions  and  a  notation  to  indicate  additional 
information  contained  on  more  screens,  the  Registry  Data  Detail  Screen  shall  provide 
the  following  information: 

1)  The  violation  number; 

2)  The  date  that  a  returned  name  and  address  request  was  posted  to  the  Vendor's 
PVPMISS; 

3)  The  expiration  date  of  the  plate  at  the  time  of  the  request  (date  returned  by 
RMV); 

4)  The  registration  vehicle  make  as  recorded  by  the  RMV; 

5)  The  registration  vehicle  make  as  recorded  on  each  ticket; 

6)  A  notation  that  the  information  was  provided  by:  (a)  the  RMV,  (b)  was 
manually  updated  to  the  system  or  (c)  other  (i.e.,  NCOA); 

7)  The  RMV  error  code,  if  any,  provided  by  the  RMV; 

8)  Returned  mail  (Nixie)  data. 
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(4.8.10)  Suspension  Detail  Screen 


This  Suspension  Detail  Screen  shall  contain  information  regarding  suspension 
information  for  each  ticket  assigned  to  a  license  plate 

The  Suspension  Detail  Screen  should  accommodate  a  minimum  of  ten  violation  records 
(per  plate)  per  screen  prior  to  scrolling  to  'page  2',  etc.,  for  a  particular  plate. 

In  addition  to  summary  level  registration  data,  instructions  for  performing  additional 
functions  and  (if  applicable)  a  notation  to  indicate  additional  information  contained  on 
more  screens,  the  following  information  must  be  provided  for  each  ticket: 

1)  Ticket  number; 

2)  The  date  the  suspension  is  to  be  lifted; 

3)  Date  and  time  of  the  hearing  to  be  held; 

4)  The  final  disposition  code  of  the  ticket  including  any  reduction  in  amount 
due. 


(4.8.11)  Chronological  Payment  Data  Screen 

The  Chronological  Payment  Data  Screen  shall  contain  information  regarding  the  most 
recent  ticket  payments  for  a  plate  in  order  of  latest  payment  first. 

The  Chronological  Payment  Data  Screen  should  accommodate  a  minimum  of  ten 
violation  records  (per  plate)  per  screen  prior  to  scrolling  to  'page  2',  etc.,  for  a  particular 
plate. 

In  addition  to  summary  level  registration  data,  instructions  for  performing  additional 
functions  and  (if  applicable)  a  notation  to  indicate  additional  information  contained  on 
more  screens,  the  following  information  must  be  provided  for  each  ticket: 

1)  Ticket  Number; 

2)  Type  of  payment  related  transaction,  for  example,  'Payment'  or  'Bounced 
Check'; 

3)  Method  of  each  payment,  e.g.,  cash,  check,  etc.; 

4)  Location  of  most  recent  payment/adjustment; 

5)  Amount  of  most  recent  payment; 

6)  Payment  batch; 

7)  Date  payment  was  updated  to  PVPMISS. 


(4.8.12)  Alternate  Name  /  Previous  Plate  Ownership  Screen 

The  Alternate  Name/Previous  Ownership  Screen  shall  provide  information  regarding: 
(a)  the  name  associated  with  a  ticket  when  that  name  is  different  from  the  registrant 
name  (for  example,  for  lease  and  rental  registrations),  and  (b)  SWAP  tickets,  i.e.,  when 
a  registrant  'swaps'  one  plate  for  another  but  still  has  tickets  outstanding  on  the  initial 
plate.  While  the  City  desires  these  two  functional  areas  to  be  included  on  one  screen, 
they  may  be  separated  onto  separate  screens. 

The  Alternate  Name/Previous  Plate  Screen  should  accommodate  a  minimum  of  ten 
violation  records  (per  plate)  per  screen  prior  to  scrolling  to  'page  2',  etc.,  for  a  particular 
plate. 
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In  addition  to  summary  level  registration  data,  instructions  for  performing  additional 
functions  and  (if  applicable)  a  notation  to  indicate  additional  information  contained  on 
more  screens,  the  following  information  must  be  provided  for  each  ticket: 

1)  Ticket  Number; 

2)  SWAP  Plate  shows  the  plate  number  to  which  the  ticket  was  issued  if  said 
plate  number  is  different  from  plate  record  that  was  accessed; 

3)  Alternate  Name  shows  the  name  associated  with  the  ticket  (such  as  for  a 
rental  customer)  when  said  name  is  different  from  the  plate  record  name  / 
registrant  that  was  accessed; 

4)  Lease/Rental  Indicator  which,  if  notated,  shall  indicate  that  the  plate  is  a 
rental/lease  or  multi-owner  vehicle; 

5)  Effective  Date,  which  (a)  for  a  SWAP  plate  is  the  effective  date  of  the 
vehicle/plate  that  received  the  ticket,  and  (b)  for  a  lease/rental/multi  owner 
plate  and  SWAP  plate  is  the  latest  effective  date  on  record. 


(4.8.13)  Ticket  Initial  Processing  /  Pending  System  Action  Detail  Screen 

The  Ticket  Initial  Processing/Pending  System  Action  Screen  shall  provide  a  summary 
of  initial  processing  action  and  scheduled  impending  (system  generated)  action. 

The  Ticket  Initial  Processing/Pending  System  Action  Screen  should  accommodate  a 
minimum  of  ten  violation  records  (per  plate)  per  screen  prior  to  scrolling  to  'page  2', 
etc.,  for  a  particular  plate. 

In  addition  to  summary  level  registration  data,  instructions  for  performing  additional 
functions  and  (if  applicable)  a  notation  to  indicate  additional  information  contained  on 
more  screens,  the  following  information  must  be  provided  for  each  ticket: 

1)  Ticket  Number; 

2)  Date  ticket  was  added  to  the  Master  Violations  File; 

3)  The  Batch  Number  and  Julian  Date  in  which  the  ticket  was  processed; 

4)  The  microfilm  number  on  which  the  ticket  was  recorded; 

5)  The  Next  System  Generated  Action  (and  the  scheduled  Date)  to  be  taken  on 
the  ticket,  for  example,  initial  name  and  address  request,  subsequent  name 
and  address  request,  next  specific  notice  type  to  be  generated,  non-renewal 
action,  etc. 
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(4.8.14)  Issuing  Officer  Detail  Screen 

The  Issuing  Officer  Detail  Screen  shall  contain  information  regarding  the  issuing  officer 
for  each  parking  ticket  assigned  to  a  plate. 

The  Issuing  Officer  Detail  Screen  should  accommodate  a  minimum  of  ten  violation 
records  (per  plate)  per  screen  prior  to  scrolling  to  'page  2',  etc.,  for  a  particular  plate. 

In  addition  to  summary  level  registration  data,  instructions  for  performing  additional 
functions  and  (if  applicable)  a  notation  to  indicate  additional  information  contained  on 
more  screens,  the  following  information  must  be  provided  for  each  ticket: 

1)  Ticket  Number; 

2)  The  Agency  Code  of  the  issuing  officer  (e.g.,  BTD,  Boston  Police  Dept.,  Fire 

Dept.,  etc.); 

3)  The  Division  (of  the  Agency),  if  applicable,  of  the  issuing  officer  (e.g.,  MDC 

Police/Division  2); 

4)  The  Badge  Number  of  the  issuing  officer; 

5)  The  Route  Number  in  which  the  ticket  was  issued; 

6)  The  Color  Code  of  the  vehicle  as  recorded  on  the  ticket; 

7)  The  Make  of  the  vehicle  as  recorded  on  the  ticket; 

8)  The  Style  of  the  vehicle  as  recorded  on  the  ticket; 

9)  The  Meter  Number  associated  with  the  ticket,  if  any; 
10)  The  Time  of  ticket  issuance  (two  times  if  applicable); 
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(4.8.15)  Ticket  Status  Screen 


The  Ticket  Status  Screen  shall  contain  summary  information  regarding  notices  sent  and 
the  payment  status  for  each  ticket  assigned  to  a  plate. 

The  Ticket  Status  Screen  should  accommodate  a  minimum  of  ten  violation  records  (per 
plate)  per  screen  prior  to  scrolling  to  'page  2',  etc.,  for  a  particular  plate. 
In  addition  to  summary  level  registration  data,  instructions  for  performing  additional 
functions  and  (if  applicable)  a  notation  to  indicate  additional  information  contained  on 
more  screens,  the  following  information  must  be  provided  for  each  ticket: 

1)  Ticket  Number; 

2)  Issue  Date; 

3)  Most  Recent  Notice  Type  Sent  for  each  ticket; 

4)  Date  Of  The  Most  Recent  Notice  Type  Sent  for  each  ticket; 

5)  The  Current  Status  of  each  ticket  which  shall  include  the  following  Status 
types:  Unpaid,  Paid,  Penalty  Dismissal,  Dismissed,  Hold/Suspended,  Seizure 
Eligible,  Non-Renewal  Action  Taken; 

6)  The  Date  The  Current  Status  Was  Recorded; 

7)  Fine  Amount  for  each  ticket; 

8)  Combined  Penalty  Amount  for  each  ticket; 

9)  Total  Amount  Due  for  each  ticket; 
10)  Total  Amount  Paid  for  each  ticket. 


(4.8.16)  Comprehensive  Notice  Creation  Date  Detail  Screen 

The  Comprehensive  Notice  Creation  Date  Detail  Screen  shall  provide  information 
regarding  the  processing  /  creation  dates  for  each  type  of  notice  sent  for  each 
corresponding  ticket. 

The  Comprehensive  Notice  Creation  Date  Detail  Screen  should  accommodate  a 
minimum  of  ten  violation  records  (per  plate)  per  screen  prior  to  scrolling  to  'page  2', 
etc.,  for  a  particular  plate. 

Further,  a  minimum  of  five  notices  and  creation  dates  (see  below)  should  be  provided 
per  ticket  per  screen. 
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In  addition  to  summary  level  registration  data,  instructions  for  performing  additional 
functions  and  (if  applicable)  a  notation  to  indicate  additional  information  contained  on 
more  screens,  the  following  information  must  be  provided  for  each  ticket: 

1)  Ticket  Number 

2)  Notice  Type  (verbiage  or  code) 

3)  Creation  or  Mail  Date  of  notice. 


(4.8.17)  Comprehensive  Non-Renewal  Hold  Data  Detail  Screen 

The  Comprehensive  Non-Renewal  Hold  Data  Detail  Screen  shall  provide  information 
regarding  each  ticket's  non-renewal  hold  status  at  the  Massachusetts  Registry  of  Motor 
Vehicles. 

The  Comprehensive  Non-Renewal  Hold  Data  Detail  Screen  should  accommodate  a 
minimum  of  ten  violation  records  (per  plate)  per  screen  prior  to  scrolling  to  'page  2', 
etc.,  for  a  particular  plate. 

In  addition  to  summary  level  registration  data,  instructions  for  performing  additional 
functions  and  (if  applicable)  a  notation  to  indicate  additional  information  contained  on 
more  screens,  the  following  information  must  be  provided  for  each  ticket: 

1)  Ticket  Number; 

2)  Hold  Status  Code  (to  accommodate  various  scenarios  relating  to  both  the 
request  and  acceptance  of  the  non-renewal-related  request  of  (a)  marks,  (b) 
mark  re-request,  (c)  clear,  (d)  clear  re-request; 

3)  SWAP  Information  (if  tickets  were  issued  to  another  plate)  to  include,  at  a 
minimum,  date  of  SWAP; 

4)  RMV  Error  Code  (the  RMV  provides  reasons  why,  for  example,  a  mark 
request  is  rejected  by  the  RMV). 


(4.8.18)  Seizure  Status  Detail  Screen 

The  Seizure  Status  Detail  Screen  shall  provide  information  regarding  the  seizure  /  boot 
status  of  each  parking  violation. 

In  addition  to  only  listing  those  violations  in  seizure  status  (and  the  date  assigned  to  said 
status),  summary  level  registration  data  must  also  be  provided  as  well  as  instructions  for 
performing  additional  functions  and  a  notation  to  indicate  additional  information 
contained  on  more  screens. 

The  Comprehensive  Non-Renewal  Hold  Data  Detail  Screen  should  accommodate  a 
minimum  of  ten  violation  records  (per  plate)  per  screen  prior  to  scrolling  to  'page  2', 
etc.,  for  a  particular  plate. 
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(4.8.19)  Correspondence  Detail  Screen 


The  Correspondence  Detail  Screen  shall  provide  information  regarding  the 
correspondence  generated  in  response  to  a  violator  inquiry,  for  each  ticket. 

The  Correspondence  Detail  Screen  should  accommodate  a  minimum  of  ten  violation 
records  (per  plate)  per  screen  prior  to  scrolling  to  'page  2',  etc.,  for  a  particular  plate. 

Summary  level  registration  data,  instructions  for  performing  additional  functions  and  a 
notation  to  indicate  additional  information  contained  on  more  screens  must  also  be 
provided. 


(4.8.20)  Disposition  Summary  Screen 

This  screen  shall  contain  information  regarding  the  hearing  and  the  subsequent 
disposition  and  payment  for  each  parking  ticket.  Summary  level  registration  data, 
instructions  for  performing  additional  functions  and  a  notation  to  indicate  additional 
information  contained  on  more  screens,  must  also  be  provided. 


(4.8.21)  Violation  Payment  Adjustment  Screen 

The  PVPMISS  must  contain  an  element  to  allow  for  the  on-line  processing  of  violation  / 
violation  related  payment  adjustments  by  authorized  City  and  Vendor  staff.  For 
example,  a  person  who  paid  a  ticket  which  was  subsequently  dismissed  at  a  hearing 
may  request  the  City  to  apply  the  amount  paid  on  the  dismissed  ticket  to  be  applied  to 
another  outstanding  violation.)  Adjustments  entered  shall  be  reflected  on-line  real-time 
in  all  systems  and  subsystems  of  the  PVPMISS. 

The  PVPMISS  must  provide  access  to  the  screen  utilized  to  perform  this  function  via 
screens  of  primary  interest. 

The  parking  violation  payment  adjustment  screen  must  contain  the  following 
information  as  well  as  instructions  for  performing  additional  functions  and  a  notation  to 
indicate  additional  information  contained  on  more  screens: 

1)  Ticket  number  for  which  adjustment  is  to  be  performed 

2)  State  plate,  registration  number  and  plate  type 

3)  Fine  amount,  penalty  amount,  amount  paid,  adjustment  amount  and  total 
amount  due  for  ticket 

4)  A  titled  field  to  record  the  total  amount  of  adjustment  (both  debit  and  credit) 

5)  A  titled  field  to  record  the  method  of  payment 

6)  A  titled  field  to  record  the  type  of  adjustment  (debit  or  credit) 

7)  BTD/OPC  Cash  Number 
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(4.8.22)  Name  and  Address  Adjustment  Screen 


The  PVPMISS  shall  allow  for  authorized  City  and/or  Vendor  staff  to  adjust  or  delete  the 
name  and  address  of  a  registrant,  on-line,  with  such  data  reflected  in  the  PVPMISS  within 
24  hours,  via  registration  number  or  ticket  number. 

For  example:  Person  (A)  returns  plate  to  RMV;  The  RMV  reissues  plate  to  person  (B). 
Person  (B)  receives  parking  tickets  but  person  (A)  receives  the  dunning  notices  for  those 
tickets.  Therefore,  the  name  and  address  on  the  PVPMISS  must  be  changed  to  reflect 
ownership  of  the  plate  by  Person  (B)  so  that  Person  (B)  can  receive  dunning  notices. 

The  PVPMISS  shall  provide  access  to  the  screen  utilized  to  perform  this  function  via 
screens  of  primary  interest. 

The  Name  and  Address  Adjustment  Screen  must  contain  the  following  information  as 
well  as  instructions  for  performing  additional  functions  and  a  notation  to  indicate 
additional  information  contained  on  additional  screens: 

•  violation  number  and  location 

•  registration  number 

•  registration  effective  date 

•  drivers  license  number 

•  last  name,  full  name,  address(es),  address  status  and  date  of  birth  of  currently  listed 
owner 

•  full  name  and  address(es)  of  'new'  owner 

•  expiration  date  of  registration 

•  a  notation  to  indicate  if  the  vehicle  is  a  rental  vehicle 

(4.8.23)  Citation  Adjustment  Screen 

The  PVPMISS  shall  allow  authorized  City  and/or  Vendor  staff  to  correct  information 
relating  to  ticket  data  or  plate  data  on-line  with  such  data  reflected  in  the  PVPMISS 
within  24  hours. 

For  example,  if  a  registration  number  was  recorded  by  the  issuing  agent  or  data  entered 
incorrectly,  OR  if  the  incorrect  violation  code  was  recorded  or  data  entered,  such  data 
must  be  corrected  on  the  PVPMISS. 

The  PVPMISS  shall  allow  access  to  the  screen  utilized  to  perform  this  function  via 
screens  of  primary  interest. 
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The  Citation  Adjustment  Screen  must  contain  the  following  information  for 
'OLD/INCORRECT'  data  as  well  as  'NEW/CORRECT'  data  and  instructions  for 
performing  additional  functions  and  a  notation  to  indicate  additional  information 
contained  on  more  screens: 

•  violation  number 

•  state  plate  (and  color,  type  and  year  for  'NEW/CORRECT'  data) 

•  violation  location  and  route 

•  violation  issue  date,  time(s),  fine  amount,  meter  number 

•  badge  #  of  issuing  agent  and  agency 

•  additional  violations  for  'NEW/CORRECT'  data 
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4.9 

ON-LINE.  REAL-TIME  CLAIMS  PROCESSING  SYSTEM 
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(4.9)  ON-LINE.  REAL-TIME  CLAIMS  PROCESSING  SYSTEM 


(4.9.0)  Real-Time  and  Comprehensively  Integrated  System  and  General  Purpose 

The  Vendor  must  provide  an  efficient  and  effective  On-Line,  Real-Time  Claims 
Processing  System  (Claims  Processing  System)  that  is  comprehensively  integrated  with 
all  systems  and  system  elements  that  are  set  forth  in  this  RFP. 

The  City  shall  utilize  the  Claims  Processing  System  for: 

1)  Public  Inquiries  That  Result  In  Disputes 

2)  Lease/Rental/Taxi  Violation  Processing. 

These  areas  are  not  mutually  exclusive.  Lease/rental/taxi  processing  can  involve 
inquiries  that  relate  to  disputes. 

Further,  and  of  great  importance,  the  numerous  transaction  types  for  'Public  Inquiries 
That  Result  In  Disputes'  are  not  mutually  exclusive  in  the  sense  that  a  non-hearing- 
related  dispute  often  results  in  a  hearing-related  dispute. 


(4.9.1)  Importance  of  System 

The  BTD/OPC  expects  to  receive  phone,  walk-in,  and  mail  inquiries  that  result  in 
disputes  at  a  proportion  of  approximately  seven  to  ten  percent  of  tickets  issued  during  a 
year.  The  City  shall  utilize  a  comprehensive  information  network  (of  which  the 
PVPMISS  is  an  integral  part)  in  conjunction  with  a  comprehensive,  responsive  and 
flexible  administrative  review  process  and  hearings  to  maximize  responsiveness  to 
public  inquiries  and  the  resolution  of  disputes.  The  Vendor's  Claims  Processing  System 
must  fully  support  the  City's  efforts  to  optimize  responsiveness. 

The  comprehensiveness  and  accuracy  of  the  data  and  information  in  the  PVPMISS,  in 
combination  with  the  ability  and  ease  of  staff  to  access  and  use  the  data  and  information 
to  maximize  responsiveness  to  the  public,  has  a  direct  bearing  on  the  City's  ability  to 
utilize  enforcement  and  collection  programs  to  achieve  compliance  with  its  traffic  and 
parking  regulations  and  attain  its  transportation  goals. 


(4.9.2)  Security  and  Controls 

The  Vendor  shall  accommodate  system  security  controls  according  to  the  City's 
specifications  over  the  processing  of  disputed  violation  dispositions  to  ensure  that  they 
are  approved  by  authorized  persons  only.  System  security  shall  be  accommodated  via 
the  restriction  to  perform  some  functions  by  authorized  City  personnel  (i.d.  level)  and 
via  the  restriction  to  perform  some  functions  by  distinct  terminal  or  workstation 
designation. 
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(4.9.3)  Direct  Access  From  General  Inquiry  Screens  and  User-Friendly.  Efficient  and 
Effective  Inquiry  and  Data  Entry 

The  Claims  Processing  System  shall  be  directly  accessed  from  any  plate-level-listing- 
of-violations  screen  that  is  described  in  the  'General/Universal  Inquiry  Screens'  section 
of  this  RFP  so  as  to  efficiently  and  effectively  utilize  PVPMISS  data  and  information 
(e.g.,  plate  number,  violation  number,  name  and  address,  violation  type,  violation 
location  and  time,  etc.)  in  a  manner  that  minimizes  data  entry  and  optimizes  the 
efficient  and  effective  use  of  data  entry. 

The  on-line  data  inquiry  and  data  entry  of  all  claims  processing  related  statuses, 
activities  and  events  must  be  provided  for  in  a  user-friendly  and  operationally 
convenient,  efficient  and  effective  manner. 

The  Claims  Processing  System  shall  provide  for  the  selection  for  processing  of:  (i)  a 
single  ticket  and  (ii)  a  group/sequence  of  tickets. 

Also,  the  Claims  Processing  System  shall  at  a  minimum  provide  for  the  selection  of  the 
following  categories  of  tickets  for  processing:  (a)  all  open  tickets  (greater  than  zero 
amount  due),  (b)  tickets  which  are  seizure  eligible,  (c)  tickets  which  are  marked  for 
non-renewal  of  driver's  license  or  registration,  and  (d)  all  tickets  whether  open  or  closed 
(zero  or  less  amount  due). 

Further,  summary  dispute  claims  information  shall  be  displayed  at  the  plate  and  ticket 
level  as  described  in  the  'General/Universal  Inquiry  and  Customer  Service  Screens' 
section  of  this  RFP.  This  information  shall  include  case  number,  dispute  code, 
abbreviated  dispute  description,  date  and  time  of  suspend,  date  of  request,  date  of 
reactivation,  date  of  update,  hearing  date  and  time,  and  result  of  dispute  (e.g.,  dismissed, 
penalty  dismissed,  denied,  etc.). 


(4.9.4)  Data  Capture  of  Name  and  Address 

As  stated,  when  the  name  and  address  of  the  person/entity  making  a  dispute  is  the  same 
as  the  registered  owner,  the  Claims  Processing  System  shall  provide  for  the  automatic 
capture/input  of  this  data. 

However,  the  name  and/or  address  of  the  person/entity  making  a  dispute  is  sometimes 
(for  disputes)  or  always  (for  lease/rental/taxis)  different  from  that  of  the  registered 
owner.  For  these  cases,  the  Claims  Processing  System  must  provide  for  the  efficient 
data  entry  and  effective  handling  of  vehicle  operator  name  and  address.  The  Vendor's 
PVPMISS  shall  reflect  and  distinguish  vehicle  operator  name(s)  and  address(es)  at  the 
violation  level  while  retaining  the  registered  vehicle  owner's  name  and  address  at  the 
registration  level.  Further,  this  shall  be  provided  in  a  manner  that  ensures  that  the 
operator  name  is  only  data  entered  once  (unless  a  correction  is  required)  regardless  of 
subsequent  updates  to  the  dispute  record. 

Communications  (letters  of  reply)  from  the  City  relating  to  a  disputed  ticket  shall  utilize 
the  violation  level  name  and  address. 
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(4.9.5)  Inquiries  That  Result  In  Disputes 


(4.9.5.0)  General  Functionality 

In  addition  to  other  requirements  set  forth  in  this  section,  the  Vendor  must  provide  for 
the  following  functions: 

a)  upon  completion  of  data  entry,  place  violation(s)  in  suspend/hold  status  for 
various  lengths  of  time  depending  upon  claims  type; 

b)  update  or  re-classification  of  claim; 

c)  automatically  decrement  disputed  tickets  from  seizure  eligibility  determinations; 

d)  automatically  prevent  the  taking  of  non-renewal  action  for  disputed  tickets  that 
are  not  in  non-renewal  status; 

e)  automatically  hold  late  penalties  temporarily  in  abeyance; 

f)  automatically,  temporarily  or  permanently  discontinue  noticing  of  disputed 
violations; 

g)  temporarily  (and  automatically)  back  out  late  penalties  pending  reactivation  of 
violations  whose  claims  'receipt  date'  (postmark  date)  was  prior  to  penalty 
application  date; 

h)  record  dismissals  of  late  penalties  due  on  outstanding  violations; 

i)  record  dismissals  of  unpaid  parking  fines; 

j)  automatically  schedule  hearings  based  on  hour,  day  and  other  scheduling 
parameters; 

k)  automatically  reactivate  the  normal  processing  of  disputed  violations  that  are  not 
dismissed  and  that  remain  outstanding,  i.e.,  resume  penalty  assessment,  normal 
noticing,  boot  determination,  RMV  processing,  etc; 

1)  generate  letters  in  accordance  with  specifications  provided  by  the  City; 

m)  maintain  history  of  claims  transactions. 
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(4.9.5.1)  Important  Characteristics  and  General  Categories  of  Disputes 


The  Vendor  shall  accommodate  the  following  general  categories  of  disputes  which  shall 
require,  subject  to  increase,  approximately  sixty  (60)  to  eighty  (80)  separate  dispute 
codes: 

1)  SUMMARY  DISMISSALS  --  such  as  'broken  meter',  'deceased  registrant', 
'valid  resident  parking  sticker',  etc.,  can  be  summarily  dismissed  without  need 
for  either  a  hearing  or  further  investigation  due  to  supporting  documentation. 
For  this  category  of  dispute,  the  summary  dismissal  is  typically  the  initial 
dispute  transaction. 

2)  REQUESTS  REQUIRING  BTD  VERIFICATION  --  are  put  on  hold  pending  a 
BTD  investigation  of  a  'broken  meter',  'sign  verification'  or  other  matter. 
Following  the  investigation,  the  violation(s)  in  question  is  either:  (a)  dismissed 
by  staff,  or  (b)  denied  by  staff  with  a  time-based  option  to  appeal  the  violation 
further  via  a  hearing.  In  the  event  that  an  investigation  cannot  be  completed 
within  a  time  parameter  to  be  determined  by  the  City,  the  System  shall 
automatically  dismiss  the  violation. 

3)  REQUESTS  REQUIRING  ADDITIONAL  DOCUMENTATION  --  are  put  on 
hold  for  a  specified  time  period  pending  receipt,  from  the  customer,  of 
supporting  documentation  such  as  a  'stolen  license  plate/stolen  vehicle  report', 
'proof  of  vehicle  disability',  'proof  of  payment',  etc.  Following  receipt  of 
documentation,  the  violation  can  be  dismissed  or  denied  (said  denial  would  be 
specific,  such  as  'proof  of  payment  was  for  another  violation'). 

4)  DENIAL  OF  REQUEST  FOR  SUMMARY  DISMISSAL  --  are  put  on  hold 
pending  instructions  from  the  customer.  This  category  of  dispute  requires  a 
general  denial  response  from  the  City  in  addition  to  specific  explanations  of 
denial  to  individuals  who,  due  to  misinterpretation  of  parking  regulations  (such 
as  a  Handicap  Plate  parking  in  a  'No  Stopping  or  Standing'  area,  etc.),  believes 
that  their  violation  should  be  summarily  dismissed  without  the  need  for  a 
hearing.  These  claims  are  put  on  hold  for  a  specified  time  period  pending  the 
customers  decision  to  pursue  the  matter  at  a  hearing  (which  depending  upon 
circumstances,  could  be  via  the  mail  or  in  person). 

5)  REQUEST  FOR  HEARING  —  for  claims  requiring  subjective  judgement  (for 
example,  a  'Hydrant'  or  other  public  safety  violation  that  is  completely  and 
accurately  filled-out)  or,  following  an  investigation  with  an  adverse  judgement 
(for  example,  the  BTD  found  that  the  sign  was  clearly  visible,  etc.);  or 
following  customer  instruction  for  a  violation  on  hold. 

6)  MISCELLANEOUS  —  for  example,  'I  never  received  ticket  on  car  and 
therefore  should  not  pay  late  penalty',  'general  suspend'  which  allows  the  City 
to  put  a  violation  on  hold  for  a  flexible  time  period  (for  bankruptcies,  etc.),  etc. 
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It  is  very  important  to  note  that,  with  the  exception  of  'summary  dismissal'  transactions, 
all  of  these  claims  are  subject  to  re-classification  to  another  category  and  claim  type 
depending  upon  customer  instructions.  More  than  half  of  all  original  claim  types/codes 
are  re-classified  by  City  staff.  Therefore,  it  is  of  the  utmost  importance  that  original 
dispute  records  be  updated  and  re-classified  in  a  manner  that  only  requires  the  insertion 
of  an  updated  transaction  code. 

Further,  an  initial  letter  with  pre-programmed  text  corresponding  to  the  specific  claim 
type  shall  be  automatically  generated  by  the  Vendor  prior  to  the  start  of  the  business 
day  following  input  of  the  original  transaction  code  (see  below)  so  that  the 
correspondence  can  be  mailed  on  that  day.  Excluding  in-person  hearing  decisions, 
subsequent  letters  corresponding  to  an  updated  claim  type  shall  also  be  generated  by  the 
Vendor  in  similar  fashion.  For  example,  a  customer  who  requests  a  hearing  for  a  claim 
that  was  denied  shall  receive  correspondence  regarding  the  scheduled  hearing. 

At  present  (and  subject  to  increase),  there  are  approximately  one  hundred  (100)  claims 
processing  correspondence  letter  types  that  can  be  sent  to  a  customer. 

Regarding  transaction  codes,  the  City  desires  to  employ  'straight'  numeric  codes.  At 
present,  the  City  utilizes  three  character  numeric  transaction  codes.  This  code  format  is. 
also  used  for  transactions  other  than  claims  processing  correspondence,  e.g.,  penalty  #1 
dismissal  -  however,  each  code  is  unique  to  a  particular  transaction. 


(4.9.5.2)  Correction  and  Revision  Capability 

Due  to  vague  or  unclear  instructions  from  the  public  or  due  to  the  misinterpretation  of  a 
request  on  the  part  of  City  staff,  a  claim  record  may  have  to  be  re-classified  to  another 
claim  code.  Also,  a  dismissal  record's  batch  number  may  have  to  be  corrected  since 
batch  numbers  are  currently  assigned  manually  from  a  pre-arranged  listing  and  errors 
occur  on  occasion.  The  Claims  Processing  System  must  accommodate  on-line  revisions 
to  an  original  or  revised  claims  processing  record. 

Corrections/revisions  must  be  accommodated  at  any  point  in  time  prior  to  re-activation 
of  the  violation  in  question. 

In  the  event  that  a  revision  is  made  on  the  same  day  that  the  original/initial  record  was 
created,  only  correspondence  relating  to  the  revised  claim  shall  be  generated. 

A  history  of  the  original  (incorrect)  transaction  data  must  be  maintained  and  must  be 
accessible. 

Once  a  Claims  Processing  record  has  been  revised,  the  System  must  clearly  and 
prominently  display  a  notation  of  said  action  for  all  subsequent  inquiries. 
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(4.9.5.3)  Case  Number  for  Non-Dismissals 


The  On-Line  Claims  Processing  System  shall  assign  a  system  generated  'case  number' 
(at  present  11  characters)  to  each  non-dismissal  claim  transaction.  (The  case  number 
for  non-dismissal  claim  transactions  updated  to  dismissals  manually  is  overlaid  [i.e., 
data  entered],  with  a  batch  number  by  City  staff.)  The  case  number  must  be  reflected  at 
the  ticket  level. 

The  Vendor  shall  provide  edits  to  ensure  only  one  case  number  is  assigned  per  ticket 
regardless  of  the  number  of  transactions  performed  at  the  ticket  level.  For  example,  a 
complaint  regarding  a  missing  sign  would  be  assigned  a  case  number  upon  data  entry  of 
the  complaint  (the  first  transaction).  If  the  investigation  into  the  missing  sign  provided 
no  basis  to  dismiss  the  violation  and  the  complaint  was  then  updated  to  a  hearing  (  a 
subsequent  transaction)  a  new  case  number  shall  not  be  assigned. 

In  addition  to  name  and  ticket  number,  the  On-Line  Claims  Processing  System  shall 
accommodate  efficient  and  user-  friendly  access  to  disputed  ticket  claims  via  case 
number. 

Case  number  for  claim  transactions  processed  via  the  Correspondence  Imaging 
Workflow  System  shall  be  the  workflow-system-generated  document  identification 
number. 


(4.9.5.4)  Batch  Number  for  Dismissals 

As  discussed  in  the  preceding  paragraphs,  the  On-Line  Claims  Processing  System  shall 
accommodate  the  entering  of  a  batch  number  for  dismissed  violations.  This  number 
shall  be  reflected  in  the  PVPMISS  at  the  ticket  level. 


(4.9.5.5)  Claims  Processing  Prior  to  Violation  Record  Update 

The  Vendor  shall  provide  for  the  complete  processing  of  claims  transactions  prior  to  the 
update  to  the  Master  Violations  File  of  a  violation  record.  Upon  update  of  the  violation 
record  to  the  Master  Violations  File,  the  claims  transaction  shall  be  included  with  the 
violation  record. 
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(4.9.5.6)  Additional  Requirements 


The  Vendor  shall  provide  for  the  following  additional  requirements: 

a)  Add  registrant  names  and  addresses  on-line  when  necessary.  This  refers  to  plate 
records  that  are  absent  of  name  and  address  information  or  where  the 
information  is  inaccurate.  This  requirement  is  also  discussed  in  various  sections 
of  this  RFP  such  as  'RMVs  Interface'  and  'Dunning  Notice  System'. 

b)  Assess  boot  eligibility  via  unique  correspondence  code.  Refer  to  'Boot  and  Tow' 
section  of  this  RFP. 

c)  Adjust  violation  type  and  fine  amount  information  according  to  the  City's 
written  instructions.  This  is  needed  in  the  event  a  'Zone  A'  No  Parking  violation 
(for  $55)  should  actually  be  a  'Zone  B'  No  Parking  violation  (for  $10),  etc. 

d)  Reassign  names  and  addresses  to  outstanding  violations  in  the  event  a 
determination  is  made  that  an  existing  name  and  address  is  no  longer  valid. 

e)  Re-apply  payment  amounts  from  one  violation  to  another  violation  and  retain 
debit/credit  data. 

f)  Decrement  from  overpaid  or  dismissed  violations  the  amount  of  refund  made. 


(4.9.5.7)  Hearing  Scheduling 

The  Vendor  shall  accommodate,  in  a  real-time  mode,  the  scheduling  of  adjudication 
hearings  via  the  following  elements  and  features: 

a)  Accommodate  the  selection  of  a  determination  of  the  number  of  hearing  slots 
available,  scheduled,  and  open  for  any  given  day  or  time,  and  capability  for 
manual  override. 

b)  Accommodate  an  on-line  message  with  manual  override  to  prevent  scheduling 
of  the  same  tickets  twice,  and  on-line  edit  features  to  ensure  valid  date,  time  and 
hearing  officer  code. 

c)  Accommodate  automatic  search  and  scheduling  of  open  time  slots  based  on 
hearing  officer  availability  and  hearings  capacity  for  specific  dates  and  hours  of 
the  day. 

d)  Accommodate  a  nightly  update  to  close  scheduling  hearings  if  the  hearing  date 
is  within  a  specified  time  period,  with  capability  for  manual  override.  For 
example,  hearings  shall  be  scheduled  a  minimum  of  ten  (10)  days  in  advance. 
Therefore,  the  On-Line  Correspondence  System  shall  accommodate  an  edit  to 
ensure  that  a  hearing  date  of  less  than  ten  (10)  days  from  the  current  date  is  not 
selected. 

e)  Accommodate  a  minimum  of  six  (6)  different  types  of  hearings.  The  On-Line 
Correspondence  System  shall  utilize  acceptable  codes  (a  distinct  code  for  each 
type  of  hearing  )  to  reflect  this  data  in  the  Master  Violations  File. 

f)  Accommodate  the  printing  of  hearing  disposition  forms  on-line,  real-time. 
Specifications  for  this  form  shall  be  provided  by  the  City. 
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(4.9.5.8)  Hearing  Dispositions 


The  Vendor  shall  accommodate,  in  a  real-time  mode,  the  updating  of  hearing 
dispositions: 


a)  Accommodate  system  logic  to  incorporate  table  values  (or  suitable  alternative) 
for  hearing  dispositions,  to  include  the  holding  of  respondents  liable  for  fines 
and/or  penalties;  reduce  the  amount  owed;  reduce  penalties;  administratively 
dismiss  violations;  indicate  a  failure  to  appear  by  the  violator;  or  indicate  a 
denial  of  a  request  for  a  hearing.  The  system  logic  shall  ensure  automatic 
settling  of  fines  and  penalties  after  the  entry  of  a  disposition  action,  and  on-line 
editing  to  ensure  that  the  disposition  code  entered  matches  the  codes  pre- 
entered  into  the  system  by  the  Vendor. 

b)  Accommodate  the  entering  of  data  relating  to  each  hearing,  including  officer 
code,  type  of  hearing,  disposition  code  and  reduced  amount  or  elimination  of 
fine  and/or  penalty. 

c)  Accommodate  the  entering  of  a  single  disposition  for  all  tickets,  being 
contested  at  the  hearing,  on  a  registration. 


(4.9.5.9)  On-Line  Edits  and  Controls 

The  Vendor  must  provide  comprehensive  edits  and  controls  for  this  important  function. 

The  Vendor  must  provide  on-line  editing  to  ensure  that  the  disposition  code  entered 
matches  a  code  pre-entered  into  the  System  by  the  Vendor. 

The  Vendor  must  provide  on-line  editing  to  ensure  that  the  disposition  code  can  be 
entered  only  once  or  that  duplicate  entry  results  in  a  single  transaction. 

Further,  the  Vendor  must  provide  on-line  system  logic  to  incorporate  table  values  (or 
some  other  type  of  effective  edit  and  control)  for  all  dispute  transaction  codes  so  as  to 
prevent  an  undesirable  combination  of  codes. 
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(4.9.5.10)  Reports 


The  Vendor  shall  deliver  to  the  City  daily  reports  of  all  dispositions  processed  which 
shall  contain  cumulative  processing  totals  for  the  current  week,  month  and  fiscal  year  as 
well  as  daily  totals  of  all  dispositions  processed  by  terminal  and  clerk  identification 
number. 

The  Vendor  shall  deliver  to  the  City  the  following  On-Line  Claims  Processing  System 
reports: 

a)  A  daily  report  listing,  by  process  date  and  user  i.d  /  name,  for  each  transaction, 
the  type  of  letter  sent,  name  of  the  correspondent,  ticket  number(s),  state  plate 
and  registration  number. 

b)  A  daily  report  listing,  in  data  entry  case  number  order,  all  tickets  processed  for 
a  hearing  hold  (pending  scheduling  of  a  hearing  date)  on  a  daily  basis. 

c)  A  daily  report  listing  the  scheduling  of  all  tickets  for  a  hearing  date  on  a  daily 
basis. 

d)  A  daily  report  listing,  by  batch  number  order,  all  violations  dismissed  on  a 
daily  basis. 

e)  A  weekly  report  of  all  correspondence  activity  for  each  process  day  in  the 
reporting  period  listing  the  number  of  each  type  of  correspondence  letter  sent. 

f)  A  daily  report  of  all  suspend  transactions  processed  on  a  daily  basis. 
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(4.9.5.11)  Non-Hearing  Processing  Screen 


The  Vendor  shall  accommodate  the  on-line  processing  of  non-hearing  disputed  ticket 
claims  from  a  single  claims  processing  screen.  Upon  completion  of  data  entry,  non- 
hearing  dispute  transactions  shall  be  reflected  on-line  real-time  in  all  PVPMISS  systems 
and  subsystems. 

The  PVPMISS  must  provide  access  to  the  screen  utilized  to  perform  this  function  via 
screens  of  primary  interest  /  usage  and  other  processing  screens.  The  Non-Hearing 
Processing  Screen  must  contain  the  following  information  as  well  as  instructions  for 
performing  additional  functions: 

a)  Date  and  time  of  inquiry 

b)  System  access  i.d.  number  of  the  staff  person  performing  the  transaction 

c)  Screen  title 

b)  Automatically  assigned  alphanumeric  case  number 

e)  A  titled  field  to  record  the  type  of  dispute  and  a  notation  as  to  how  the  inquiry 
was  received 

f)  The  name,  with  the  last  name  repeated,  and  address  of  the  registrant 

g)  A  titled  field  to  prompt  letter  generation 

h)  A  titled  field  to  record  an  internal  BTD/OPC  comment  code 


(4.9.5.12)  Suspend  Processing  Screen 

The  Vendor  shall  accommodate,  from  a  single  claims  processing  screen,  the  on-line 
processing  of  violation  dispositions  resulting  in  the  generic  temporary 
cessation/suspension  of  system  activity  for  such  violations.  Upon  completion  of  data 
entry,  these  transactions  shall  be  reflected  on-line  real-time  in  all  PVPMISS  systems 
and  subsystems. 

The  PVPMISS  must  provide  access  to  the  screen  utilized  to  perform  this  function  via 
screens  of  primary  interest.  The  Suspend  Processing  Screen  must  contain  the  following 
information  as  well  as  instructions  for  performing  additional  functions: 

a)  Date  and  time  of  inquiry 

b)  Date  and  time  of  processing 

c)  Screen  title 

d)  A  titled  field  to  record  the  reason  for  suspension  activity 

e)  Automatically  assigned  alphanumeric  case  number 

f)  Date  on  which  system  activity  will  resume 

g)  A  titled  field  to  indicate  the  number  of  days  activity  will  be  held  in  abeyance 

h)  A  titled  field  to  record  a  BTD/OPC  internal  code  or  comments 

i)  A  titled  field  to  record  the  type  of  letter  associated  with  the  suspension 
transaction  and  how  the  inquiry  was  received 

j)   A  titled  field  to  prompt  letter  generation 

k)  The  system  access  i.d.  number  of  the  staff  person  performing  the  suspension 
transaction 

1)  The  full  name,  with  last  name  repeated,  and  address  of  the  registrant 
m)  Confirmation  of  completion  of  the  transaction. 
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(4.9.5.13)  Hearing  Request  Screen 

The  Vendor  shall  accommodate  the  on-line  processing  of  hearing  requests  from  a  single 
claims  processing  screen.  Upon  completion  of  data  entry,  hearing  request  transactions 
shall  be  reflected  on-line  real-time  in  all  PVPMISS  systems  and  subsystems. 

The  PVPMISS  must  provide  access  to  the  screen  utilized  to  perform  this  function  via 
screens  of  primary  interest.  Hearing  transactions  entered  must  be  reflected  on-line  real- 
time in  all  PVPMISS  systems  and  subsystems. 

The  Hearing  Request  Screen  must  contain  the  following  information  as  well  as 
instructions  for  performing  additional  functions: 

a)  Date  and  time  of  inquiry 

b)  Screen  title 

c)  A  titled  field  to  record  the  hearing  officer 

d)  A  titled  field  to  record  the  hearing  date 

e)  A  titled  field  to  record  the  hearing  time 

f)  A  titled  field  to  record  the  hearing  room 

g)  A  titled  field  to  record  the  date  on  which  system  activity  will  resume 

h)  A  titled  field  to  record  the  hearing  type 

i)  A  titled  field  to  record  BTD/OPC  comments 
j)  The  BTD/OPC  alphanumeric  case  number 

k)  The  number  of  hearing  appointments  available 

1)  The  number  of  hearing  appointments  required  for  the  transaction 

m)  A  titled  correspondence  record  section  to  include: 

i)  A  titled  field  to  record  the  type  of  correspondence  associated  with  the 
hearing  request  and  how  the  request  was  received 

0 

ii)  A  titled  field  to  prompt  letter  generation 

iii)  The  name,  with  last  name  repeated,  and  address  of  the  registrant 
n)    Confirmation  of  completion  of  the  transaction 
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(4.9.5.14)  Hearing  Outcome  Processing  Screen 

The  Vendor  shall  accommodate  the  on-line  processing  of  parking  violation  and 
violation  related  hearing  outcomes  from  a  single  claims  processing  screen.  Hearing 
outcome  transactions  entered  must  be  reflected  on-line  real-time  in  a  all  PVPMISS 
systems  and  subsystems. 

The  PVPMISS  must  provide  access  to  the  screen  utilized  to  perform  this  function  via 
screens  of  primary  interest.  The  Hearing  Outcome  Processing  Screen  must  contain  the 
following  information,  instructions  for  performing  additional  functions  and  a  notation  to 
indicate  additional  information  contained  on  more  screens: 

a)  Date  and  time  of  inquiry 

b)  Screen  title 

c)  A  titled  field  to  indicate  the  inclusion  of  multiple  violations  in  the  transaction 

d)  A  titled  field  to  record  the  hearing  officer 

e)  A  titled  field  to  record  the  BTD/OPC  code  and  plea 

f)  A  titled  field  to  record  BTD/OPC  comments 

g)  A  titled  field  to  record  the  date  and  time  of  the  hearing 

h)  A  titled  field  to  record  the  BTD/OPC  type  of  hearing  and  hearing  room 

i)  The  BTD/OPC  alphanumeric  case  number 

j)  The  total  dollar  amount  due  for  the  ticket(s)  involved 

k)  The  ticket  number  involved 

1)  A  titled  field  to  record  the  final  disposition  code 

m)  A  titled  field  to  record  the  final  plea 

n)  A  titled  field  to  record  the  ticket  reduction  amount 

o)  The  dollar  amount  of  the  violation  fine 

p)  The  dollar  amount  of  up  to  five  individual  penalties 

q)  The  total  dollar  amount  due  for  the  violation 

r)  Confirmation  of  completion  of  the  transaction 
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(4.9.5.15)  Note  Regarding  Claims  Processing  Screens: 


Prospective  Vendors  shall  be  advised  that  it  is  acceptable  to  combine  more  than  one 
claims  processing  requirement  onto  a  single  screen  —  so  long  as  said  screen  is  user- 
friendly  and  efficient  and  effective. 


(4.9.6)  Lease/Rental/Taxi  Vehicle  Ticket  Claim  Processing 

Lease  /  Rental  /  Taxi  Vehicle  Claims  Processing  is  designed  to  coordinate  the  special 
handling  of  violations  identified  to  leasing  companies,  rental  agencies  or  taxi 
companies.  Lease,  rental  and  taxi  registrants  are  not  held  liable  for  violations  incurred 
by  the  vehicle  operator  given  that  the  registrant  complies  with  the  provisions  of 
Massachusetts  General  Laws,  Chapter  90,  Section  20E  as  amended  by  Chapter  699,  acts 
of  1985.  The  law  can  be  summarized  as  providing  for: 

-  Issuing  the  registered  owner  of  the  vehicle  a  written  notice  of  each  violation 
stating  required  ticket  issuance  data  (Note:  The  Vendor  must  generate  and  send 
this  initial  dunning  notice). 

-  Within  forty-five  (45)  days  from  the  date  of  noticing  the  registered  owner  is  to 
supply  the  City  with  the  name  and  address,  date  of  birth,  and  license  number  of 
the  vehicle  operator  responsible  for  the  violation.  Compliance  with  this 
provision  of  the  law,  along  with  payment  of  a  surcharge,  shifts  the  burden  of 
violation  payment  to  the  operator  of  the  vehicle. 

-  The  City  will  upon  receiving  the  operator  name  and  address,  issue  a  hearing 
notice  to  the  operator  of  the  vehicle. 

-  If  the  operator  information  is  not  forwarded  to  the  City  within  the  45  day  period, 
the  registered  owner  of  the  vehicle  is  held  liable  for  the  violation.  In  these  cases 
the  City  will  not  assign  the  violation  to  the  operator  of  the  vehicle  when  the 
name  is  supplied  after  the  deadline. 

-  The  Parking  Clerk  collects  a  60  cent  surcharge  fee  for  each  lease,  rental  or  taxi 
contract  written  in  the  City  of  Boston. 

The  Vendor  shall  provide  the  capability  to  turn  off  the  regular  dunning  notice  program, 
suspend  the  violation,  remove  a  penalty,  record  a  hearing  date  and  disposition  data  as 
well  as  noticing  data. 

The  Vendor  shall  also  provide  follow-up  dunning  notices  and  shall  provide  audit  and 
tracking  reports  for  surcharge  payments. 


125 


(4.9.6.0)  Lease  /  Rental  /  Taxi  Vehicle  System  Functions 


The  Vendor  shall  accommodate  the  processing  of  the  dispositions  of  lease,  rental  and 
taxi  vehicle  disputed  ticket  claims  against  the  PVPMISS.  The  processing  of  such 
dispositions  requires  that  the  On-Line  Claims  Processing  System  accommodate  the 
following  functions: 

a)  the  entering  of  vehicle  operator  name,  address  and  other  data  at  the  violation 
level.  There  may  be  different  names  and  addresses  for  each  violation  contained 
on  a  registration  and  the  system  shall  accommodate  the  entering  of  such  data  as 
well  as  the  retention  of  the  name,  address  and  other  data  associated  with  the 
registered  owner  of  the  license  plate  at  the  license  plate  level. 

b)  the  temporary  backing  out  of  late  penalties  due  on  outstanding  violations 

c)  the  automatic  scheduling  of  hearings  for  violations  issued  to  lease,  rental  and 
taxi  vehicles  upon  receipt  and  entering  of  vehicle  operator  data  to  the  On-Line 
Claims  Processing  System. 

d)  the  printing  of  a  hearing  disposition  form  via  the  On-Line  Inquiry  System  which 
shall  contain  data  relative  to  the  dispute  of  lease,  rental  and  taxi  vehicle 
violations,  specified  by  the  City. 

The  On-Line  Claims  Processing  System  shall  accommodate  a  minimum  of  two  different 
correspondence  letters  to  be  sent  on  violations  issued  to  lease,  rental  and  taxi  vehicles. 
The  On-Line  Claims  Processing  System  shall  utilize  acceptable  codes  (a  distinct  code 
for  each  type  of  letter)  to  reflect  this  data  in  the  PVPMISS. 

The  On-Line  Claims  Processing  System  shall  accommodate  a  distinct  code  to  reflect  the 
automatic  scheduling  of  a  hearing  for  violations  issued  to  lease,  rental  and  taxi  vehicles. 
These  distinct  codes  shall  be  utilized  to  reflect  this  data  in  the  PVPMISS. 


(4.9.6.1)  Lease  /  Rental  /  Taxi  Processing  Screen 

The  City  shall  utilize  the  features  of  the  'Hearing  Request  Screen'  (discussed  in  the 
preceding  pages)  for  this  function. 


(4.9.7)  Mailing  of  Claims  Processing  System  Correspondence  /  Letters 

The  vendor  shall  be  responsible  for  the  mail-house  services  and  subsequent  delivery 
of  all  Claims  Processing  System  related  correspondence  /  letters  (e.g.,  disputes, 
hearings,  lease  vehicle,  taxi)  to  the  U.S.  Postal  Service  as  set  forth  in  Section 
4.11.17,  'Location  of  Notice  Generation  /  Printing  and  Mail  House  Functions'. 


126 


4.10 

REGISTRY  OF  MOTOR  VEHICLES  fRMVs)  INTERFACE 
SYSTEM  AND  REQUIREMENTS 
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(4.10)  REGISTRY  OF  MOTOR  VEHICLES  fRMVs)  INTERFACE 
SYSTEM  AND  REQUIREMENTS 


(4.10.0)  Vendor/RMVs  Personnel  Interface  and  Relationships  and  Other  Vendor 
Responsibilities 

The  Vendor  must  remain  completely  current  with  RMVs  (especially  the  MA  RMVs) 
specifications,  technical  or  otherwise,  and  modifications  or  changes  to  the  RMVs  data 
bases,  systems  and  procedures  related  to  the  PVPMISS. 

Further,  an  inherent  responsibility  of  the  Vendor  is  to  continuously  analyze  and  research 
the  elements  that  compose  RMVs  data  and  information. 

The  Vendor  must  interface  with  the  RMVs  personnel  through  telephone,  memorandum 
and  face-to-face  communications  so  as  to  develop  (where  necessary),  maintain  and 
nurture  a  constructive,  efficient  and  effective  working  and  collaborative  relationship 
with  the  RMVs,  especially  the  MA  RMV,  regarding: 

a)  the  day-to-day  and  ongoing  operations  of  the  PVPMISS,  and 

b)  RMVs  systems  and  operational  changes  or  modifications  that  will  directly, 
indirectly  or  potentially  impact  PVPMISS  operations. 

The  responsibilities  of  the  RMVs  are  numerous,  diversified  and  wide-ranging  in  scope. 
In  addition,  resource  constraints  are  experienced  by  the  RMVs.  These  realities  dictate 
that  the  City's  PVPMISS  management  must,  in  effect,  compete  with  numerous  interests 
within  RMVs  and  external  to  RMVs  (especially  the  MA  RMV)  for  RMVs 
considerations  and  resources. 

The  Vendor's  required  ongoing  operational  contact  with  the  RMVs,  in  combination  with 
the  required  and  anticipated  Vendors  expertise  in  RMVs  interface,  places  the  Vendor  in 
a  unique  position  to  collaborate  with  RMVs  (especially  the  MA  RMV)  regarding:  (1) 
the  resolution  of  technical  issues  that  effect  the  PVPMISS,  and  (2)  acquiring,  and  acting 
upon  under  direction  from  (and  in  concert  with)  the  City,  information  regarding  planned 
changes  to  the  parking  ticket  segment  of  RMVs  systems  or  to  changes  to  RMVs 
systems  that  will  impact  the  PVPMISS. 


(4.10.1)  Manipulation  and/or  Interpretation  of  Data 

The  front-end  capture  of  data  and  information  (which  includes,  for  example,  the 
keypunch  of  parking  ticket  data  and  the  update  of  that  data  to  the  PVPMISS)  and  the 
matching  of  Vendor-provided  data  and  information  with  returned  RMVs  data  and 
information  shall  require  the  accurate,  efficient  and  effective  manipulation  and/or 
interpretation  of  data.  This  requirement  is  due  to  the  realities  and  fundamental  nature  of 
the  PVPMISS  environment  and  results  from  the  dynamic  nature  of  registrant  data  and 
information  as  well  as  variability  and/or  inconsistency  of  data  that  may  be  provided  to 
or  returned  by  RMVs. 
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For  example: 

An  RMV  database  may  contain  different  registrants  for  a  registration,  or 
different  plate  issue  dates  for  the  same  registrant  who  receives  more  than  one 
ticket; 

A  motorist  may  register  their  vehicle  with  the  same  registration  number  under 
the  name  'John  Smith'  during  one  registration  period  and  as  'John  T.  Smith'  for  a 
different  registration  period; 

An  issuing  agent  may  neglect  to  notate  plate  type  on  the  parking  ticket  but 
sufficient  information  exists  to  successfully  and  accurately  proceed  with  RMVs 
interface; 

As  issuing  agent  mat  indicate  a  plate  type  by  writing  an  alpha  prefix  as  part  of 
the  registration  number; 


(4.10.2)  The  Parking  Ticket 

The  Boston  parking  violation  ticket  document  is  the  initial  and  front-end  link  to  RMVs 
interface  for  an  issued  violation.  The  Vendor  must  efficiently  and  effectively  utilize 
data  and  information  from  the  ticket  in  the  conduct  of  their  RMVs  interface 
responsibilities. 

The  parking  ticket  is  now  in  two  versions.  One  is  the  handwritten  type  and  the  other  is 
electronically  generated  from  hand-held  ticket  writing  devices.  Copies  of  the  parking 
tickets  and  instructions  to  issuing  agents  are  provided  in  the  Appendixes  Document  of 
this  RFP.  In  addition  to  other  information  set  forth  in  this  section,  these  will  help 
provide  an  understanding  of  the  critical  function  of  interfacing  with  RMV  databases  and 
the  treatment  of  various  data  elements  such  as  license  plate  types. 


(4.10.3)  License  Plate  Type  Requirement 

Numerous  license  plate  types  exist  and  must  be  accurately,  efficiently  and  effectively 
handled  by  the  Vendor.  Within  a  particular  plate  type  there  may  also  exist  a  variety  of 
sub-types.  The  Vendor  must  accommodate  the  different  interface  requirements  of  the 
RMVs  in  conjunction  with  data  from  the  parking  ticket  in  their  treatment  of  plate  types. 

The  RMVs  Interface  System  must  have  the  capability  to  distinguish  between  different 
license  plate  types  and  between  license  plate  numbers  that  have  identical  configurations 
but  that  are  distinct  entities  because  they  are  different  license  plate  types,  e.g.,  passenger 
plate  123456  and  commercial  plate  123456. 

In  order  to  identify  and  distinguish  license  plate  types,  the  system  must  segregate  the 
tickets  of  the  license  plate  owners  and  report  through  the  on-line  system  whether  the 
license  plate  is  'passenger',  'commercial',  or  'other'  type.  The  number  of  plates  required 
to  be  distinguished  could  increase  if  the  RMVs  increase  the  number  of  pate  types.  The 
Vendors  registrant  requester  systems  must  have  the  capability  to  identify  the  correct 
registrant  due  to  this  and  other  similar  factors. 

"Other"  plate  types  (e.g.,  Taxi,  Trailer,  Bus,  School  Bus,  etc.)  are  presently  identified  at 
the  point  of  ticket  issuance  by  the  writing  of  two  or  three  character  alpha  prefixes  before 
the  characters  of  the  license  plate. 
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(4.10.4)  License  Plate  Color  Requirement 


For  MA  license  plates,  the  RMVs  Interface  System  must  distinguish  between  license 
plates  according  to  the  color  of  the  plate  characters.  Plate  color  capture  and  utilization 
is  required  whether  plate  numbers  are  unique  configurations  or  are  identical,  differently 
colored  plates.  Plate  colors  that  are  currently  in  use  are  green,  red  and  blue.  In  the 
event  the  RMV  creates  other  plate  colors  the  vendor  would  be  required  to  add  that  color 
to  their  programming. 


(4.10.5)  Significant  Character  Requirement 

The  Vendor  must  accurately,  efficiently  and  effectively  accommodate  the  treatment  of 
'significant'  license  plate  characters.  These  are  plate  characters  that  are  neither  alpha 
nor  numeric  but  are  significant  in  that  they  are  required  for  the  correct  identification  of 
a  plate  owner  or  to  distinguish  between  plate  owners. 

At  present,  for  MA  plates  this  requirement  relates  to  dots  (".")  for  vanity  plates  and 
lightning  bolts  for  ham  operator  plates.  Also,  the  New  Hampshire  RMV  employs  plus 
("+")  and  minus  ("-")  signs,  along  with  other  characters,  with  their  plate  series. 


(4.10.6)  Multiple  Owner  and  Re-Issued  License  Plate  Requirement 

The  RMVs  Interface  System  must  efficiently  and  effectively  accommodate  all  scenarios 
where  a  license  plate  number  and  type  has  been  issued  to  more  than  one  registrant  at 
different  periods  of  time.  The  system  must  correctly  assign  tickets  to  the  license  plate 
owner  who  is  responsible  for  their  issuance. 


(4.10.7)  Splits  and  Combines 

When  tickets  are  issued  to  a  specific  registrant  during  one  or  more  registration  period  of 
the  same  license  plate  and  registrant  data  varies  even  slightly  compared  with  previously 
received  data,  then  the  undesirable  creation  of  separate  registration  files  may  occur.  To 
address  this  reality,  the  Vendor  must  provide  at  a  minimum  automated,  point-of-update 
logic  to  prevent  a  license  plate  from  incorrectly  separating  ('splitting')  into  more  than 
one  record. 

The  Vendor  must  also  provide  at  a  minimum  the  on-line  capability  for  City  personnel  to 
correct  records  that  were  "split".  This  would  occur  when  a  registration  was  incorrectly 
"split"  because  the  level  of  variability  in  name  and  address  information  would  require 
human  judgment  to  resolve.  The  on-line  correction  of  split  registration  records  would, 
by  necessity,  be  driven  by  a  weekly,  Vendor  provided  split  plate  report  in  state  plate 
order. 
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4.10.8)  Request  and  Processing  of,  and  Edits  and  Controls  for,  Massachusetts  Vehicle 
Owner  Information 

The  Vendor  must,  at  a  minimum,  request  on  a  weekly  basis  vehicle  owner  (registrant) 
information  from  the  Massachusetts  Registry  of  Motor  Vehicles  database  for  each 
registration  number  appearing  on  issued  tickets  that  are  not  completely  paid  or 
dismissed  within  a  time  parameter  (from  the  date  of  issuance)  established  by  the  City 
(currently  15  days). 

The  selected  request  and  acquisition  interface  option  with  the  RMV  database  must 
maximize  benefits  to  the  City  in  regard  to  hit  rate,  accurate  registrant  identification  and 
efficiency. 

The  Vendor's  RMVs  Interface  System  must  contain  comprehensive  criteria,  edits  and 
controls  so  that  both  the  availability  and  integrity  of  data  are  efficiently  and  effectively 
optimized. 

The  Vendor  shall  be  proficient  in  the  use  of  all  registrant  related  data  from  parking 
ticket  documents. 

In  order  for  a  license  plate  record  to  be  returned  by  the  MA  RMV,  the  fundamental 
requirement  is  that  the  date  that  the  plate  was  issued  to  the  registrant  cannot  be  a  point 
in  time  after  the  parking  ticket  was  issued  to  the  plate.  The  Vendor  must  be  responsible 
for  the  subsequent  interpretation,  edit  and  control  of  the  data  on  the  returned  record  and 
the  accurate,  efficient  and  effective  update  and  matching  of  returned  records  to  existing 
records  or  creation  of  new  records. 

The  Vendor  shall  add,  edit  and  control  to  the  Master  Violations  File  newly  acquired 
license  plate  and  registrant  information,  including  but  not  limited  to  the  following: 
name,  address,  vehicle  make,  driver's  license  number,  date  of  birth,  plate  issue  date, 
confirmation  date  of  received  request,  expiration  date  of  license  plate,  RMV  error  code, 
plate  type  and  plate  color. 

The  Vendor  shall,  at  its  cost,  purchase  from  the  Massachusetts  RMV,  a  new  updated 
monthly  file  of  all  registrants.  The  Vendor  must  have  the  capability  to  utilize  this  file  to 
obtain  registrant  data.  The  Vendor  should  also  have  the  capability  to  receive  and  obtain 
registrant  data  on  a  weekly  basis  via  tapes. 

The  Vendor  shall  add,  match,  edit  and  control  to  existing  Master  Violations  File  records 
license  plate  and  registrant  information,  including  but  not  limited  to  the  following: 
name,  address,  vehicle  make,  driver's  license  number,  date  of  birth,  plate  issue  date, 
confirmation  date  of  received  request,  expiration  date  of  license  plate,  RMV  error  code, 
plate  type  and  plate  color,  and  custodial  data  for  leased  vehicles  if  available. 

The  RMVs  Interface  System  must  also  provide  edits  and  controls  of  the  type  that 
include,  but  are  not  limited  to:  analysis  of  license  plate  configuration;  correct  treatment 
of  company  or  corporate  names;  exclude  skeletal  tickets;  exclude  pending  requests; 
exclude  completely  paid  or  dismissed  tickets. 
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In  the  course  of  utilizing  returned  registrant  records,  and  in  order  to  ensure  the  integrity 
of  information,  registrant  identification  information  edits  and  controls  should  be  applied 
on  both  ticket  and  plate  level  records  and  at  key  process  control  points. 

The  RMVs  Interface  System  must  accommodate  changes  or  modifications  to  criteria, 
edits  and  controls  in  an  efficient  and  effective  manner. 

Upon  acquisition  of  registrant  information,  the  Vendor  must  provide  for  the  immediate 
on-line  system  access  of  parking  ticket  information  by  registrant  name,  driver's  license 
number,  violation  number  and  registration  number. 

The  Vendor  may  also  be  required  to  utilize  the  RMVs  database  for  research  and  other 
purposes  (i.e.,  generate  special  notices  to  all  registrants  of  commercial  vehicles). 


(4.10.9)  RE-Request  and  Processing  of  MA  Vehicle  Owner  Information 

The  Vendor  must  provide  a  system  for  re-requesting  and  processing  vehicle  owner 
information  from  the  Massachusetts  RMV  for: 

tickets  that  fail  violator  noticing  edit  criteria  such  as  license  plate  issue  date 
match;  and 

tickets  assigned  to  plates  for  which  registrant  data  was  not  contained  on  the 
initial  request. 

For  any  single  violation,  the  City  would  typically  require  two  distinct  re-requests  of 
vehicle  owner  information. 

The  time-lag  between  an  initial  request  and  eligibility  for  a  subsequent  re-request,  and 
between  an  unsuccessful  re-request  and  eligibility  for  a  subsequent  (i.e.,  second)  re- 
request  may  normally  be  forty-five  (45)  days. 

Re-requests  must  be  conducted,  at  a  minimum,  on  a  monthly  basis  for  violations  issued 
to  MA  license  plates. 


(4.10.10)  ON-LINE  Request  and  Processing  of  MA  Vehicle  Owner  Information 

The  requirements  relating  to  MA  RMV  Request  and  RE-request  of  vehicle  owner 
information  set  forth  in  the  preceding  paragraphs  are  presently  initiated  through 
Vendor/RMV  batch  processing.  However,  in  light  of  MA  RMV  interface  trends  and 
projections,  the  Vendor  will  likely  be  required  to  implement  an  on-line  system  for  the 
purpose  of  requesting  and  processing  MA  registrant  data.  In  such  an  event,  the  Vendor 
may  be  required  to  also  continue  to  accommodate  batch  interface  with  the  RMV,  the 
level/volume  of  which  would  be  determined  by  future  developments. 
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(4.10.11)  Request  and  Processing  of.  and  Edits  and  Controls  for.  Out-of-State  Vehicle 
Owner  Information 

The  Vendor  must  request  on  a  routine  basis  vehicle  owner  (registrant)  information  from 
the  various  out-of-state  Registry  of  Motor  Vehicles  for  each  registration  number 
appearing  on  issued  tickets  that  are  not  completely  paid  or  dismissed  within  a  time 
parameter  (from  the  date  of  issuance)  established  by  the  City  (currently  15  days). 

The  City  is  extremely  interested  in  and  desires  routine  and  frequent  registrant 
information  requests.  The  frequency  of  requests  shall  be  conducted  on  the  most 
advantageous  schedule  allowed  and  shall  be  based  upon:  (a)  the  need  to  acquire 
information  at  the  earliest  date;  and  (b)  minimum  volume  requirements  or  other  request 
criteria  established  by  a  particular  state  RMV. 

The  RMVs  Interface  System  (for  non  MA  states)  must  utilize  the  same  types  of  adding 
and  matching  requirements  and  edits  and  controls  described  for  Massachusetts  vehicle 
owner  information  described  in  the  preceding  paragraphs.  However,  variability  will 
exist  between  states  and  the  Vendor  must  efficiently  and  effectively  accommodate 
different  license  plate  assignment  systems,  processing  rules  and/or  matching  criteria. 

For  out-of-state  registrant  identification,  the  City  recognizes  that  the  treatment  or 
availability  of  driver's  license  number,  date  of  birth,  and  plate  color  may  vary. 

Due  to  variability  among  various  states  and  the  possible  lack  of  information  of  the  type 
provided  by  the  Massachusetts  RMV,  vehicle  make  must  be  included  as  an  up-front  edit 
and  control  element  for  out-of-state  RMVs.  However,  the  Vendor's  RMVs  Interface 
System  must  eliminate  instances  where  a  request  transaction  should  be  completed,  but 
is  not,  due  to  an  incorrect  failure  of  a  vehicle  make  match.  For  example,  a  vehicle  make 
of  "GMC"  (General  Motors  Corporation)  may  be  correctly  entered  onto  the  violation 
ticket  by  an  issuing  agent  as  the  vehicle  make  while  a  particular  RMVs  data  file  may  list 
the  vehicle  make  as  "Pontiac".  For  this  example,  the  "GMC"  make  is  in  fact  a  "Pontiac" 
make. 


(4.10.12)  RE-Request  and  Processing  of  Out  of  State  Vehicle  Owner  Information 

The  Vendor  must  provide  a  system  for  re-requesting  and  processing  vehicle  owner 
information  from,  at  a  minimum,  high  issuance  out-of-state  RMVs  for: 

tickets  assigned  to  plates  for  which  the  state  RMV  could  not  provide  registrant 
data  on  the  initial  request  or  the  data  could  not  be  adequately  matched. 

The  specific  high  issuance  out-of-state  RMVs  will  be  identified  via  consultation  with 
the  City.  At  present  they  include  New  York,  New  Jersey,  Maine,  Rhode  Island  and 
Pennsylvania. 

For  any  single  violation  issued  to  a  top  issuance  state,  the  City  would  typically  require  a 
single  re-request  of  vehicle  owner  information. 

The  time-lag  between  an  initial  request  and  a  subsequent  re-request  must  be  approved 
by  the  City  and  shall  be  based  upon:  (a)  the  need  to  acquire  this  information  at  the 
earliest  date;  and  (b)  a  consideration  of  the  reason(s)  why  the  initial  request  or  re- 
request  was  unsuccessful.  Re-requests  should  be  conducted,  at  a  minimum,  on  a 
quarterly  basis  for  violations  issued  to  out-of-state  registrations. 
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(4.10.13)  Identification  and  Analysis  of  Unsuccessful  Vehicle  Owner  Identification 
Transactions 

For  both  the  MA  RMV  and  Out  of  State  RMVs,  the  Vendor  must  identify,  via  a 
comprehensive  report,  the  reasons  why  registrant  data  was  not  provided  by  an  RMV. 

This  report  shall  break-down  into  separate  categories  the  reasons  why  information  was 
not  provided  and  shall  provide  appropriate  volume  and  percentage  information  for  these 
categories. 


(4.10.14)  RMVs  System  Interface  Required  for  the  Maximum  Possible  Number  of 
Non  MA  States 

Violations  issued  to  out-of-state  license  plates  account  for  approximately  fourteen 
percent  (14%)  of  all  tickets  issued  annually.  The  City,  as  one  component  of  traffic  and 
parking  management,  is  committed  to  collect  and  adjudicate  the  maximum  possible 
number  of  violations  that  are  issued.  Also,  the  City  is  committed  to  an  equitable  and 
consistent  approach  in  this  endeavor  through  the  equal  concentration  of  efforts 
wherever  possible. 

Toward  these  ends,  the  City  requires  the  Vendor  to  provide  registrant  information  for 
the  maximum  possible  number  of  license  plates  for  the  maximum  possible  number  of 
out-of-state  RMVs  (including  Washington  D.C.),  regardless  of  whether  a  particular 
state's  interface  is  conducted  in  an  automated  or  manual  manner. 

On  the  following  page  are  listed  all  non-MA  states  in  order  of  their  historical  and 
anticipated  volume  issuance.  Each  state's  out-of-state  volume  of  issuance  is  also 
included. 

It  should  be  noted  that  a  particular  state's  percentage  of  out-of-state  issuance  may,  in 
isolation,  appear  to  be  statistically  insignificant.  However,  in  combination  with  other 
such  states  the  percentage  may  be  statistically  significant. 


(4.10.14.0)  IMPORTANT:  In  regard  to  the  state  of  Vermont,  it  has  historically  proven 
to  be  problematic  in  terms  of  requesting  registrant  owner  information.  As  a  minimum 
requirement,  the  City  requires  the  Vendor  to  provide  registrant  information  for  the 
following  fifteen  (15)  non-MA  states:  New  Hampshire,  New  York,  Rhode  Island,  New 
Jersey,  Connecticut,  Maine,  Pennsylvania,  Florida,  California,  Virginia,  Maryland, 
Illinois,  Ohio,  Texas,  and  Michigan.  However,  it  is  to  the  City's  advantage  to  obtain 
registrant  information  from  as  many  additional  non-MA  states  as  possible.  (NOTE:  For 
Connecticut,  due  to  current  cost  considerations,  the  Vendor  may  only  be  required  to 
obtain  registrant  data  for  registrations  with  two  or  more  outstanding  citations.) 

It  should  be  noted  that  the  City  will  always  be  concerned  about  any  issues  relative  to  the 
above  fifteen  states  which  could  be  problematic  in  terms  of  requesting  registrant  owner 
information.  In  the  event  that  a  Proposer  is  aware  that  any  such  issues  do  exist  to  the 
extent  that  said  issues  would  or  could  significantly  impact  the  City's  objectives,  a 
Proposer  should  address  the  matter  in  their  proposal  and  propose  alternative  non-MA 
RMV  interface(s)  which  would  approximate  the  problematic  state's  relative  issuance. 
Also  note,  the  City  and  the  State  of  New  Hampshire  have  an  agreement  that  no  dunning 
notices  will  be  produced  and  sent  where  the  vehicle  make  on  the  ticket  does  not  match 
the  vehicle  make  received  from  NH. 
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4.10.15  HISTORICAL  AND  ANTICIPATED 


OUT-OF-STATE  ISSUANCE 


FY  2009  Out  of  State  Issuance:  194,485 


State 

Issuance 

State 

Issuance 

1)  New  Hampshire 

39,949 

(26) 

Oklahoma 

709 

2)  New  York 

25,197 

(27) 

Missouri 

637 

3)  Connecticut 

22,773 

(28) 

Deleware 

555 

4)  Rhode  Island 

19,761 

(29) 

Wisconsin. 

526 

5)  New  Jersey 

13,349 

(30) 

Wash  D  C 

452 

6)  Maine 

11,041 

(31' 

Alabama 

392 

7)  Florida 

7,909 

(32) 

T  .ouisiana 

357 

8)  Pennsylvania 

7,584 

(33) 

Kentuckv 

286 

9)  Vermont 

4,773 

(34' 

Iowa 

270 

10)  Virginia 

3,602 

(35) 

Oregon 

264 

11)  Maryland 

3,515 

(36) 

W.  Virginia 

261 

12)  California 

3,440 

(37) 

Kansas 

256 

13)  Texas 

2,399 

(38) 

New  Mexico 

246 

14)  Illinois 

2,343 

(39) 

Nevada 

210 

15)  Ohio 

2,343 

(40) 

Utah 

188 

16)  North  Carolina 

2,127 

(41) 

Mississippi 

187 

17)  Michigan 

2,027 

(42) 

Nebraska 

142 

18)  Georgia 

1,914 

(43) 

Arkansas 

128 

19)  Arizona 

1,504 

(44) 

Montana 

112 

20)  Indiana 

1,392 

(45) 

Alaska 

84 

21)  South  Carolina 

1,105 

(46) 

Idaho 

81 

22)  Colorado 

1,051 

(47) 

Hawaii 

56 

23)  Tennessee 

959 

(48) 

S.  Dakota 

46 

24)  Washington 

794 

(49) 

N.  Dakota 

30 

25)  Minnesota 

760 

(50) 

Wyoming 

30 
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(4.10.16)  Massachusetts  "Section  5"  License  Plate  Registrant  Identification  Information 

The  MA  RMV  maintains  a  separate  file  of  a  category  of  license  plates  referred  to  as 
Section  5  plates.  The  primary  type  of  plates  of  immediate  interest  to  the  City  within 
this  category  are  the  'dealer  normal'  and  'dealer  vanity'  plates. 

At  a  minimum  of  once  a  year,  at  the  City's  direction,  the  Vendor  must  secure  (in  tape 
format)  from  the  MA  RMV  registrant  identification  information  for  the  complete  file  of 
Section  5  plates.  The  Vendor  must  accurately,  efficiently  and  effectively  apply  this 
information  to  the  Master  Violations  File  for  those  'dealer  normal'  and  'dealer  vanity' 
registrations  that  have  outstanding  tickets. 

In  addition  to  applying  these  registration  records  to  the  Master  Violations  File,  the 
Vendor  shall  be  required  to  create  Multi  Owner  records  of  dealer  entities  in  accordance 
with  specifications  described  in  the  'Multi  Owner  System'  section  of  this  RFP. 

Further,  in  accordance  with  Multi  Owner  System  specifications,  the  Vendor  must 
provide  for  the  consolidated  noticing  of  these  plates  through  the  Statement  of  Parking 
Violations  Notice  and  Seizure  Notice  and  must  make  seizure  eligible  those  dealer  plates 
that  qualify  for  seizure. 


(4.10.17)  Canadian  Vehicle  Owner  Information 

The  City  expects  the  Vendor  to  maximize  registrant  data  acquisition  by  providing 
interfaces  to  Canadian  Provinces  for  the  purpose  of  securing  vehicle  owner  information. 

In  FY  2009,  approximately  1,100  tickets  were  issued  to  vehicles  registered  in  the 
Province  of  Ontario. 


(4.10.18)  Data  Entry  of  Vehicle  Owner  Information 

The  Vendor  must  allow  for  the  manual  data  entry/input  of  vehicle  owner  information 
for  all  license  plate  records. 

The  Vendor's  RMVs  Interface  System  must  be  able  to  accommodate:  (a)  the  creation  of 
a  registrant  record  where  no  record  exists,  and  (b)  the  overlay  of  a  new  registrant  record 
onto  an  existing  record.  In  the  case  of  a  record  overlay,  the  'removed'  record  must  be 
retained  in  a  history  file. 

In  terms  of  the  requirements  for  this  section,  the  on-line  data  entry  of  registrant 
information  is  required,  at  a  minimum,  for  three  distinct  processes: 

(1)  Where  the  Vendor  is  instructed  by  City  staff  or  where  City  staff  elect  to 
perform  themselves:  (a)  entering  of  an  initial  plate  record  onto  an  existing 
blank  record;  and  (b)  overlaying  (substituting)  a  correct  registrant  record 
over  an  incorrect  record  (which  was  initially  returned  by  an  RMV  as  the 
result  of  a  registrant  information  request); 

(2)  Where  City  staff  have  through  independent  research  identified  a  vehicle 
owner  for  the  purpose  of  seizure  or  to  generate  on-line  collection  letters;  and 
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(3)  Where  the  Vendor  is  instructed  by  the  City  to  accommodate  name  and/or 
address  changes  to  registrant  data  obtained  via  the  National  Change  of  Address 
Registry  (NCOA). 

Each  source  of  a  registrant  record  must  be  distinctly  noted  by  the  Vendor's  system. 

Changes  to  a  registrant  record  in  the  Vendor's  system  as  a  result  of  scenario  number  (1) 
above,  must  be  treated  by  the  Vendor's  system  as  being  received  by  an  RMV  (as  RMV 
documentation  is  provided  to  and  approved  by  the  Vendor).  The  new  registrant  record 
must  then  be  eligible  for  all  time  and  eligibility  based  events  set  forth  in  this  RFP.  For 
example,  the  new  record  would:  receive  an  Overdue  Notice  and  any  other  applicable 
notices;  be  reviewed  for  seizure  eligibility  according  to  seizure  criteria;  be  reviewed  for 
non-renewal  eligibility  according  to  non-renewal  criteria;  etc. 

For  the  addition  of  a  registrant  record  made  by  City  staff  as  a  result  of  scenario  number 
(2)  above,  action  relating  to  the  addition  of  a  registrant  record  may  be  limited,  at  that 
point  in  time,  to  the  transaction  of  principal  interest.  For  example,  the  new  record 
would  receive  On-Line  Claims  Processing  System  type  notices  but  would  not  receive 
Overdue,  Impending  License  Suspension  or  Registry  Action  Notification  notices. 


(4.10.19)  License  and  Registration  Non-Renewal:  Mark  Request  and  Processing  and 
Edits  and  Controls 

The  Vendor  shall  generate  and  refer  'Mark  Input  Records'  to  the  Massachusetts  RMV  so 
as  to  allow  the  RMV  to  match  user  (i.e.,  the  Vendor)  transaction  input  to  the  correct 
records  on  the  RMV  database  for  the  purpose  of  vehicle  registration  non-renewal  and 
driver's  license  non-renewal  for  unpaid  tickets. 

The  Vendor  shall  subsequently  retrieve  and  process  returned  'Mark  Response  Records' 
from  the  RMV. 

This  interface  with  the  RMV  must  be  in  accordance  with  RMV  specifications  for  large 
volume  non-renewal  transactions. 

The  RMV  interprets  the  identification  of  a  registration  to  be  composed  of  four  main 
components: 


1.  Registration  Number: 

2.  Plate  Type: 

3.  Plate  Color: 

4.  Issue  Date: 


The  digits  and/or  letters  stamped  on  the 
plate 

A  three  letter  code  used  to  identify  the 
classification  of  the  plate 
A  one  letter  code  used  to  identify  the  color 
of  the  plate 

Date  of  original  issue  of  the  registration. 


The  intent  of  the  above  structure  is  for  a  given  combination  of  these  fields  to  be  unique 
at  any  single  moment  in  time. 
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In  addition,  key  data  elements  required  by  the  RMV  for  all  non-renewal  transactions  are 
the  Parking  Ticket  Number(s)  and  Violation  Date(s). 

The  Vendor  must  control  their  EDP  environment  and  the  data  contained  therein  in  order 
to  maintain  a  high  success  rate  while  using  this  system. 

A  violation  will  be  eligible  for  non-renewal  action  if  the  violation  is  not  in  a  suspend 
status  or  not  completely  paid  or  dismissed  one-hundred  and  five  days  (105)  after  ticket 
issuance. 

The  RMVs  Interface  System  must  contain  comprehensive  criteria,  edits  and  controls  to 
ensure  the  efficient  and  effective  determination  of  non-renewal  eligibility  and  the 
subsequent  marking  and  acknowledgment  of  such  markings  at  the  RMV. 

Upon  RMV  confirmation  of  non-renewal,  a  twenty  dollar  Registry  Fee  must  be  assessed 
to  each  affected  violation  in  accordance  with  state  law  and  ticket  and  plate  level  dollar 
amounts  due  must  be  recalculated.  However,  if  payment  is  received  (date  of  receipt  is 
determined  via  received  mail  batch  date)  or  dismissal  or  suspend  status  is  initiated  prior 
to  non-renewal  confirmation,  then  the  twenty  dollar  fee  shall  be  backed-out  and  an 
'error  clear'  transaction  shall  be  transmitted  to  the  RMV. 

Registrants  affected  by  non-renewal  action  must  be  so  notified  through  the  Noticing 
Program  and  informed  of  the  revised  dollar  amount  due. 

In  the  event  that  violations  in  non-renewal  status  are  paid  but  the  payment  is  returned  by 
the  maker's  bank  as  unpaid  due  to  a  'bad  check'  (e.g.,  bounced  check),  the  Vendor  must 
reactivate  the  violations  to  the  non-renewal  status  and  include  those  violations  in  the 
next  available  mark  transaction  interface.  Further,  the  Vendor  must  generate  and  send 
"error  clears"  to  correct  "chargeable  clears". 

At  present,  non-renewal  mark  transactions  must  be  processed  and  sent  to  the  RMV  on  a 
monthly  basis.  Mark  transactions  "returned"  by  the  RMV  must  be  updated  to  the 
PVPMISS  within  twenty-four  hours  of  their  receipt. 

At  this  time  the  City  does  not  anticipate  the  need  to  conduct  non-renewal  interface  with 
the  RMV  for  abandoned  vehicle  violations.  However,  such  interface  may  be  required  at 
a  later  date  in  time. 


(4.10.20)  License  and  Registration  Non-Renewal:  Mark  RE-Request  and  Processing 

The  Vendor  must  identify  the  reasons  why  a  referred  violator  name  and/or  license  plate 
number  was  not  accepted  by  the  RMV  for  non-renewal  action  and  re-refer  those  names 
and  plate  numbers  to  the  RMV  for  non-renewal. 

Non-renewal  mark  re-requests  should  be  sent  to  the  RMV  with  on-going  mark  requests 
and  are  presently  conducted  every  four  months. 

The  City  would  typically  require  a  single  mark  re-request  for  a  particular  ticket. 

The  time  lag  between  an  initial  and  unsuccessful  mark  request  and  the  subsequent  mark 
re-request  shall  take  into  consideration  the  need  to  achieve  a  mark  at  the  earliest  date 
and  the  reason  why  an  initial  mark  request  was  unsuccessful. 
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(4.10.21)  License  and  Registration  Non-Renewal:Clear  Request  and  Processing  and 
Edits  and  Controls 

The  Vendor  shall  generate  and  refer  'Clear  Input  Records'  to  the  Massachusetts  RMV  so 
as  to  allow  the  RMV  to  match  user  transaction  input  to  the  correct  records  on  the  RMV 
database  for  the  purpose  of  clearing  records  that  have  been  marked  for  non-renewal  that 
must  be  cleared  from  non-renewal  status  due  to  the  disposition  of  tickets,  by  payment  or 
otherwise. 

The  Vendor  shall  subsequently  retrieve  and  process  returned  'Clear  Response  Records' 
from  the  RMV. 

This  interface  with  the  RMV  must  be  in  accordance  with  RMV  specifications  for  large 
volume  non-renewal  transactions. 

The  Vendor  must  accommodate  the  "clear"  function  via  computer  tape  as  well  as  on- 
line transmission.  (Refer  to  "On-Line  Access"  requirements  discussed  at  the  end  of  this 
section.) 

Presently,  clear  transactions  must  be  processed  and  sent  to  the  RMV,  via  tape,  twice  per 
week.  Immediately  upon  becoming  eligible  for  a  non-renewal  clear,  a  marked  record 
shall  be  included  in  the  next  available  twice  per  week  clear  transactions.  Clear 
transactions  returned  by  the  RMV  must  be  updated  to  the  PVPMISS  within  twenty-four 
hours  of  their  receipt. 

The  RMVs  Interface  System  must  contain  comprehensive  criteria,  edits  and  controls  to 
ensure  the  efficient  and  effective  determination  of  non-renewal  clear  eligibility  and  the 
subsequent  clearing  and  acknowledgment  of  such  clearing  at  the  RMV. 


(4.10.22)  License  and  Registration  Non-Renewal:Clear  RE-Request  and  Processing 

The  Vendor  must  re-refer  clear  records  that  were  sent  to  the  RMV  for  non-renewal  clear 
action  but  which  were  not  accepted  by  the  RMV. 

Non-renewal  clear  re-requests  should  be  sent  to  the  RMV  at  a  minimum  on  a  quarterly 
basis. 


(4.10.23)  ON-LINE  Processing  of  Non-Renewal  Transactions 

The  requirements  relating  to  MA  RMV  non-renewal  transactions  set  forth  in  the 
preceding  paragraphs  are,  as  noted,  presently  initiated  through  Vendor/RMV  batch 
processing  for  the  vast  majority  of  transactions.  However,  the  Vendor  must  also 
provide  an  on-line  system  for  this  purpose  via  on-line  access  to  the  Massachusetts 
RMVs  Uninsured  Motorist  System  (UMS).  For  more  information,  refer  to  the 
paragraphs  in  this  section  entitled  "Provision  of  On-Line  Access  to  the  MA  RMV 
Licensing  and  Registration  System". 
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(4.10.24)  Financial  and  Other  Accounting  System  and  Adjustments  for  Non-Renewal 
Transactions 

The  RMVs  Interface  System  must  provide  for  complete  and  proper  accounting  for  all 
fees  which  are  owed  to  the  RMV  for  non-renewal  transactions. 

In  addition,  the  RMVs  Interface  System  must  provide  for  accurate  and  proper 
accounting  for  fees  which  were  originally  reported  as  owed  to  the  RMV  (by  either  the 
RMVs  or  Vendor's  system)  but  were  determined  at  a  later  date  to  be  not  owed  to  the 
RMV.  These  include,  but  are  not  limited  to: 

Tickets  with  both  a  payment  and  disposition 

Tickets  with  a  pay  date  prior  to  or  equal  to  a  mark  date 

Tickets  with  certain  hold  dates 

Tickets  with  a  charge  clear  that  were  confirmed  that  had  adjustment  transactions 
(bounced  checks,  refunds,  clerical  errors,  etc.) 

Tickets  with  a  charge  clear  that  were  not  confirmed 

Tickets  processed  via  both  batch  and  on-line  interface 


(4.10.25)  Registrant  Name  and  Address  History 

The  RMVs  Interface  System  must  provide  a  complete  history  of  registrant  name  and 
address  changes  that  may  occur  for  a  particular  license  plate  record. 

In  addition  to  providing  history  for  updated  names  and  addresses,  plate  history  must 
fully  accommodate  the  following  types  of  events:  combines,  splits,  SWAPS,  manual 
data  entry  of  registrant  identification,  nixies  and  possible  NCOA  address  changes. 

Plate  history  must  accommodate  a  minimum  of  five  occurrences  of  history  events. 


(4.10.26)  License  Plate  Swap  Program 
The  purpose  of  the  Swap  Program  is  to: 

a)  identify  and  link  vehicle  license  plates  that  have  expired,  been  canceled,  or 
have  been  turned  in  to  the  MA  RMV  with  a  newer  license  plate(s)  that  has  been 
issued  to  the  same  individual  or  business  entity,  and 

b)  have  the  reporting  capability  to  identify  all  past  and  current  license  plates  of  a 
registrant  so  that  a  determination  can  be  made  whether  to  link  the  license  plates. 

Historically,  the  MA  RMV  has  often  issued  'new'  plates  to  registrants  for  their  'old' 
plates.  Also,  the  RMV  periodically  replaces  all  plates  or  all  plates  for  specific  plate 
types  with  new  plates. 
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In  order  to  help  ensure  that  the  City  is  able  to  efficiently  and  effectively  collect  on 
tickets  that  have  been  issued  to  a  vehicle  owner's  returned  license  plate  as  well  as  those 
tickets  that  have  been  assigned  to  a  newly  issued  plate,  the  Vendor  shall  automatically, 
and  on  an  on-going  basis,  link  all  tickets  issued  to  a  vehicle  owner  and  shall  provide 
such  linkage  on-line,  at  the  plate  inquiry  level. 

The  Vendor  shall  also  provide  the  capability  to  link  (swap)  license  plates  in  a  batch  and 
on-line  mode.  (City  staff  will  typically  perform  on-line  SWAPS.  Refer  to  the  On-Line 
SWAP  screen  below.) 

License  plates  shall  be  Swapped  by  the  Vendor  on  an  on-going  basis  through  the 
matching  of  the  following  variables  or  a  combination  of  those  variables:  registrant 
name,  date  of  birth  and  driver's  license  number.  For  Swap  transactions  that  should 
occur,  the  Vendor  shall  prevent  blank  variable  fields  in  one  or  more  plate  records  from 
not  allowing  a  transaction  to  be  completed. 

When  a  Swapped  vehicle  owner's  file  is  accessed  through  the  on-line  system  the 
parking  tickets  issued  to  the  retired  license  plate  number(s)  as  well  as  the  current 
number(s)  must  be  presented.  The  Noticing  Program  must  consolidate/accommodate 
the  Swap  information  and  notice  all  outstanding  tickets  whether  they  were  issued  to  an 
old  or  current  plate. 

(4.10.27)  On-Line  SWAP  Screen 

As  discussed  above,  the  PVPMISS  shall  contain  an  element  to  allow  for  the  on-line 
processing  of  the  linking  of  tickets  associated  with  an  expired  registration  to  a  current 
registration  —  in  effect  'moving'  unpaid  parking  tickets  from  an  'old'  (expired)  license 
plate  to  a  "new"  current  license  plate,  by  authorized  City  and  Vendor  staff.  Swap 
transactions  entered  must  be  reflected  on-line  real-time  in  all  PVPMISS  systems  and 
subsystems. 

The  PVPMISS  must  provide  access  to  the  screen  utilized  to  perform  this  function  via 
screens  of  primary  interest.  The  on-line  SWAP  screen  shall  contain,  at  a  minimum,  the 
following  information  as  well  as  instructions  for  performing  additional  functions: 

1)  Screen  title 

2)  Date  and  time  of  inquiry 

3)  Expired  registration  data: 

a)  state  plate,  registration  number  and  type 

b)  effective  date  of  this  registration 

c)  the  name,  address,  license  number,  and  date  of  birth  of  the  owner  of 
record 

d)  a  notation  to  indicate  if  the  violations  are  in  a  Massachusetts  RMV  non- 
renewal status. 

4)  Current  registration  data: 

a)  state  plate,  registration  number  and  type 

b)  effective  date  of  this  registration 

c)  the  name,  address,  license  number,  and  date  of  birth  of  the  owner  of 
record 

d)  a  notation  to  indicate  if  the  violations  are  in  a  Massachusetts  RMV  non- 
renewal status. 

5)  Confirmation  of  completion  of  the  transaction. 
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(4.10.28)  Provision  of  On-Line  Access  to  the  MA  RMV  Licensing  and  Registration 
System 

The  Vendor  shall  be  required  to  provide  the  City  with  on-line  access  to  the 
Massachusetts  Registry  of  Motor  Vehicles  computer  system  for,  at  a  minimum,  three 
important  functions: 

1)  inquiry  access  to  the  Automated  Licensing  and  Registration  System 
(ALARS)  for  research  and  public  service  purposes;  and 

2)  on-line  Mark  processing  for  ticket  and  plate  records  to  be  Marked  for 
license  and  registration  non-renewal. 

3)  on-line  Clear  processing  for  ticket  and  plate  records  Marked  for  license  and 
registration  non-renewal. 


It  should  be  noted  that  on-line  non-renewal  Clear  transactions  typically  occur  when 
ticket  payment  or  resolution  is  made  at  City  Hall  and  a  "Certified  Receipt"  (which  the 
RMV  will  honor  as  proof  of  Clear)  is  issued  because  a  registrant  must  immediately 
renew  their  license  or  registration.  The  City  and/or  the  RMV  may  require  that  marked 
records  that  are  cleared  on-line  also  be  included  in  the  batch  clear  process. 

Depending  upon  developments  at  the  RMV,  the  City  may  also  require  that  lockbox 
payments  for  non-renewal  tickets,  once  updated  to  the  Master  Violations  File,  be 
transmitted  on-line  to  the  RMV  as  clear  transactions. 

The  RMV  requires  that  on-line  access  to  their  ALARS  and  Non-Renewal  System  be 
provided  in  a  host/guest  mode  within  a  system  historically  known  as  the  Uninsured 
Motorist  System  (UMS).  The  RMV  refers  to  this  technological  configuration  as  UMS- 
GUEST.  The  general  configuration  is  that  the  UMS-GUEST  runs  on  some  computer 
other  than  that  at  the  RMV.  Based  on  terminal  input,  the  UMS-GUEST  relies  on  the 
RMV  computer  for  support  (database)  services. 


(4.10.29)  Interface  to  Other  RMV  Databases 

The  Vendor  shall  be  required  to  interface  with  other  RMV  databases  such  as  the 
Handicapped  Placard  Database,  etc.,  to  obtain  information  that  may  be  required  by  the 
City  and  may  include  data  on  Stolen  Vehicles,  lessee  information  for  leased  vehicles 
and  Motor  Vehicle  Accidents. 
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4.11 

PARKING  TICKET  DUNNING  NOTICE  SYSTEM  AND  SERVICES 
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(4.11)  PARKING  TICKET  DUNNING  NOTICE  SYSTEM  AND  SERVICES 


(4.11.0)  Provision  of  a  Comprehensive.  Multi-Faceted  and  Integrated  Parking  Ticket 
Dunning  Notice  System  (Notice  System) 

The  Vendor  shall  provide  a  comprehensive  and  multi-faceted  Notice  System  for  the 
collection  of  parking  tickets. 

This  shall  include  the  complete  provision  of  all  systems  and  services  relative  to  the 
noticing  function  and  shall  include,  among  other  things:  a  primary  Massachusetts  and 
out-of-state  noticing  program;  additional  noticing;  an  On-Line  Special  Collections 
Noticing  System;  a  Notice  Management  System;  comprehensive  Mail  House  services; 
comprehensive  quality  control  and  the  processing  of  returned  mail. 

The  Notice  System  shall  be  fully  integrated  with  all  elements  of  the  PVPMISS. 


(4.11.1)  "Noticing  Program"  Document 

A  "Description  of  Noticing  Program"  document  is  provided  in  the  appendix  to  this  RFP. 

This  document  describes  a  number  of  notices  currently  utilized  as  part  of  Boston's 
PVPMISS.  In  addition,  the  sequence,  timing  and  interrelationship  of  certain  notices  is 
set  forth.  Further,  copies  of  these  notices  are  provided.  This  document  will  be  very 
helpful  in  providing  insight  to  and  understanding  of  certain  aspects  of  the  City's 
approach  to  the  dunning  notice  function  and  the  Vendor's  responsibilities  therein. 


(4.11.2)  Communication  and  Provision  of  Information  to  Violators 

The  Notice  System  is  the  primary  means  of  communication  with  parking  violators  about 
outstanding  parking  tickets.  This  communication  includes,  but  is  not  limited  to: 
provision  of  important  payment,  ticket  or  registration  status  and  appeal  information; 
notification  of  pending  enforcement  action;  notification  of  just-completed  enforcement 
action;  and  the  conveyance  of  appropriate  provisions  of  laws  for  parking  enforcement. 


(4.11.3)  Initiating  Enforcement  and  Collection  Action 

In  Boston's  PVPMISS  environment,  the  Notice  System  is  viewed  as  a  crucial,  efficient 
and  effective  tool  relative  to  scheduling  and  initiating  time  and  criteria  based  dunning 
and  enforcement  actions  that  are  taken  against  violations  and  license  plates. 

These  actions  are  critical  to  the  success  of  the  City's  enforcement  efforts  and  include  the 
seizure  of  a  vehicle  and  the  non-renewal  of  driver's  license  and  registration. 
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(4.11.4)  Primary  Massachusetts  and  Out-of-State  Noticing  Components 


The  Notice  System  shall  efficiently  and  effectively  accommodate  two  distinct  noticing 
programs  or  elements: 

1.  for  Massachusetts  registrations 

2.  for  out-of-state  registrations  (including  the  District  of  Columbia) 

For  any  single  violation  that  is  not  completely  paid  or  dismissed  that  is  issued  to 
Massachusetts  registrations,  the  Vendor  will  be  required  to  send  time  and  sequential 
based  notices,  the  number  of  which  shall  not  normally  exceed  five  (5). 

In  addition  to  these  notices,  the  Vendor  will  be  required  to  send  other  notices  presented 
in  the  "Noticing  Program"  document.  For  example,  the  vendor  will  normally/routinely 
mail  every  two  weeks  a  Seizure  Notice  to  all  newly  qualified/re-qualified  seizure  (boot) 
eligible  vehicle  owners  as  required  by  law.  (The  Seizure  Notice  is  also  discussed  in  the 
Boot  and  Tow  System  section  of  this  RFP.) 

For  any  single  violation  that  is  not  completely  paid  or  dismissed  that  is  issued  to  out-of- 
state  registrations,  the  Vendor  will  be  required  to  send  time  and  sequential  based 
notices,  the  number  of  which  shall  not  normally  exceed  four  (4). 

Also,  a  listing  of  all  newly  eligible/re-eligible  out-of-state  registrations  appearing  on  the 
seizure  list  will  be  sent  (presently  by  the  City)  to  the  appropriate  department  of  motor 
vehicles  every  two  weeks.  (The  out-of-state  Seizure  Notice  is  also  discussed  in  the 
"Boot  and  Tow  System"  section  of  this  RFP.) 

It  should  be  noted  that  out  of  state  registrations  receive  approximately  fourteen  percent 
of  all  violations  issued  and,  because  non-renewal  of  license  and  registration  are  not 
readily  available  enforcement  remedies,  the  Notice  System  for  these  populations  is  a 
crucial  collection  component. 


(4.11.5)  Ticket  and  Plate  Level  Notices 

Included  in  the  above  requirements  for  Massachusetts  and  Out-of-State  noticing,  for  any 
registration  with  outstanding  violations  the  Notice  System  will  be  required  to  evaluate 
and  assess  eligibility,  and  schedule,  create  and  generate  notices  at  the  "ticket  level" 
(ticket  level  notices)  and  at  the  "plate  level"  (plate  level  notices). 

Ticket  level  notices  may  not  necessarily  represent  a  complete  listing  of  outstanding 
violations  issued  to  a  particular  registration. 

Plate  level  notices  represent  a  complete  listing  of  outstanding  violations  issued  to  a 
particular  registration  or,  a  complete  listing  of  outstanding  violations  that  are  in  the 
same  status,  such  as  seizure  status. 

For  ticket  level  notices,  more  than  one  ticket  can  and  should  be  included  on  one  notice, 
i.e.,  "physically"  represented  on  a  single  notice.  In  such  instances,  notwithstanding 
normal  notice  run  scheduling  considerations,  the  notice  timetable  for  a  violation  shall 
not  be  lengthened  to  accommodate  the  inclusion  of  other  violations  on  the  notice.  The 
number  of  violations  that  may  be  included  on  a  ticket  level  notice  may  be  restricted  by 
payment  processing,  notice  format,  etc.,  considerations. 
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(4.11.6)  Eligibility  Criteria 


The  Vendor's  Notice  System  shall  contain  comprehensive  eligibility  criteria  which  must 
be  met  before  a  ticket  level,  plate  level  or  other  notice  may  be  generated. 

The  capability  to  generate  notices  must  accommodate  time  and  non-time  based  criteria 
that  include,  but  are  not  limited  to:  (a)  the  status  of  a  violation(s)  or  license  plate,  (b)  a 
specific  event,  activity  or  condition,  and  (c)  a  series  or  combination  of  events,  activities 
or  conditions. 


From  a  set  of  various  and  generic  variables  that  comprise  criteria,  the  City  desires  to 
"simply"  select  the  variables  that  would  be  utilized  to  create  (or  modify)  criteria  for 
different  notices. 


Changes  or  modifications,  and  additions  or  deletions  to  notice  eligibility  criteria  are  a 
certainty  due  to  the  dynamic  PVPMISS  environment.  The  City  desires  the  capability  to 
simply  revise  criteria  by  adding,  changing,  or  deleting  variables  in  a  quick,  easy  and 
effective  manner. 

Further,  revisions  to  an  existing  notice  criteria  must  be  accommodated  in  a  efficient  and 
effective  manner  with  no  or  minimum  risk  and  disruption.  It  is  desired  that  noticing  in 
general,  or  relative  to  a  particular  notice  or  functionality  of  other  elements  of  the 
PVPMISS,  are  not  negatively  impacted  by  changes  or  modifications  to  criteria. 


(4.11.7)  Examples  of  Specific  Eligibility  Criteria 

Specific  criteria  shall  include,  but  not  be  limited  to,  the  following  types  of  criteria 
variables: 


age  of  ticket 

payment  status  of  ticket 

registrant  data 

penalty  assessment 
registration  configuration 


(e.g.  number  of  days  from  issuance) 

(e.g.  fully  paid,  unpaid,  partially  paid) 

(e.g.  name  and  address  confirmed  by  RMV, 
registration  effective  date  and  expiration 
date,  registration  make,  error  code  returned) 

(e.g.  overdue  penalty  assessed,  registry  non- 
renewal penalty  assessed) 

(e.g.  some  populations  of  registrations  are 
excluded  from  normal  noticing  and  are  not 
sent  any  notices  or  are  sent  special  notices) 
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plate  type 


ticket  or  plate  suspend  status 


(e.g.  some  populations  of  plate  types  are 
excluded  from  normal  noticing  and  are  not 
sent  any  notices  or  sent  special  notices) 


notice  history 


registration  state 

number  of  tickets 
outstanding 


closed/final  disposition 
ticket/plate  status 

make  match 


swap  status 
combine  status 


(e.g.  recognizing  multiple  codes  that 
temporarily  or  permanently  hold  noticing 
activity  in  abeyance) 

(e.g.  past  notice  activity  for  ticket  and/or 
plate  including  days  from  other  notices  that 
contained  the  tickets  and/or  plate;  did/did 
not  appear  on  a  previous  notice  and/or  a 
previous  specific  notice) 

(e.g.  valid  state) 

(e.g.  running  count  of  total  tickets 
outstanding,  out-  standing  and  not 
suspended) 

(e.g.  dismissed,  fully  paid) 

(e.g.  in  non-renewal  status,  fleet  registration, 
bad  address  history,  special  registration 
population) 

(e.g.  the  make  of  the  vehicle  as  it  appears  on 
the  ticket  is  different  from  the  make  of  the 
vehicle  as  it  appears  on  the  RMVs 
registration  record) 

(tickets  from  expired  plate  moved  to  active 
plate) 

(tickets  have  been  moved  from  older  record 
on  plate  to  newer  record  on  same  plate) 
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(4.11.8)  Returned  Check  Notice 


The  Vendor  will  be  responsible  for  the  on-line  generation  of  a  "Returned  Check  Notice" 
to  persons  or  parties  whose  check  payments  have  been  returned  unpaid  by  their  banks 
(and  have  not  been  subsequently  re-paid). 

(Refer  to  the  "Bounced  Checks"  section  of  this  RFP  for  additional  discussions  that 
relate  to  returned  check  processing  and  that  should  be  considered  by  the  Vendor.) 

The  Returned  Check  Notice  shall  be  generated  at  the  same  time  the  payment  is 
decremented  from  the  system  by  the  Vendor  or  in  some  other  such  efficient  and 
effective  manner. 

In  instances  where  the  returned  check  (initially)  provided  payment  for  violations  on 
more  than  one  registration,  the  "Bounced  Check"  fee  shall  only  be  applied  to  one  (1)  of 
those  registrations. 

The  Vendor  shall  attach  the  actual  returned  check  to  the  Returned  Check  Notice  and 
mail  this  material  to  the  maker  of  the  returned  check  (via  window  envelopes). 

In  addition,  the  Vendor  shall  provide  a  notice  register  in  state/plate  order  that  shall 
provide  a  listing  of  the  plates  and  tickets  noticed  along  with  summary  notice  totals. 

The  Vendor  and  the  City  shall  account  for  and  accommodate  the  fact  that  the  maker  of  a 
returned  check  will  not  always  be  the  registered  owner,  (i.e.,  the  person/entity  who 
wrote  the  check  is  not  the  registrant).  For  this  category  of  returned  checks,  the  City  has 
traditionally  used  alternative  noticing  procedures  and  has  required  the  Vendor  to 
provide  envelopes  for  mailing  on  which  the  mailing  name  and  address  is  included. 

The  City  recognizes  that  distinctive  characteristics  relating  to  return  check  processing 
may  provide  for  alternative  solutions  to  the  noticing  function.  In  such  an  event, 
Prospective  Vendors  shall  satisfy  the  City  that  the  above  requirements  are  consistently, 
efficiently  and  effectively  accommodated. 


(4.11.9)  On-Line  Special  Collections  Noticing  System 

The  Vendor  shall  provide  an  on-line  and  integrated  Special  Collections  Noticing 
System  that  will  be  utilized  by  City  staff  to  supplement  and  complement  the  large-scale, 
computer  driven  noticing  system  elements. 

The  System  shall  allow  for  the  initiation  and  generation  of  a  letter  type  notice  series  via 
the  efficient  and  operationally  convenient  data  input  of  instructions  and  unique 
transaction  codes  to  license  plate  records. 

The  System  shall  provide  for  the  subsequent  automatic  generation  of:  (a)  a  second 
notice,  and  (b)  payment  and  activity  reports. 

The  system  must  accommodate  the  generation  of  letters:  (1)  for  license  plate  records 
that  contain  a  registrant  name  and  address;  (2)  following  the  data  input  of  registrant 
name  and  address  where  no  name  and  address  records  exist;  and  (3)  following  the 
manual  data  entry  overlay  of  registrant  name  and  address  over  an  existing  name  and 
address. 
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When  a  new  name  and  address  is  overlaid  onto  a  name  and  address  record  that  had  been 
received  by  an  RMV,  the  newly  entered  name  and  address  shall  be  temporary  and  shall 
reside  in  the  plate  history  file.  The  use  of  that  name  and  address  shall  be  limited  to  the 
activities  of  the  On-Line  Special  Collections  Noticing  System. 

The  System  shall  contain  edits  and  controls  to  ensure  that  tickets  contained  on  an  initial 
notice  that  are  completely  paid  or  dismissed,  that  have  a  hold  date,  etc.,  are  not  included 
on  the  follow-up  notice. 

In  addition,  edits  and  controls  must  account  for  or  eliminate  the  possible  occurrence  of 
operator  error,  such  as  the  duplicate  data  input  of  instructions  for  any  plate  or  ticket 
record. 

At  present,  the  City  utilizes  five  (5)  special  collection  letters  (i.e.,  transaction  codes 
which  consist  of  two  numeric  characters).  (Refer  to  the  Noticing  System  document  for 
the  existing  format  and  text.) 

The  system  must  be  flexible  and  allow  for  additional  codes  (which  would  likely  call  for 
a  three  character  numeric  code)  and  the  efficient  and  effective  modification  of  time-lags 
and  code  interactions. 
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Presented  below  is  a  transaction  code/events  matrix  that  can  most  clearly  set  forth  the 
required  type  of  scheduling  and  interrelationship  of  codes. 


Time  Line 


Dayl 


Day  35  (e.g.) 


Event  to  Trigger 
Letter  Generation 


Manual  Input 
of  Code 


Automatic  Code 
Assignment 


Code# 


Code# 


1 
2 
3 
5 


No  follow-up 
notice  is  sent. 


4 

5 
5 


In  addition  to  the  above  requirements,  the  On-Line  Special  Collections  Notice  System 
must  provide  accurate,  comprehensive  and  timely  activity  reporting.  Reports  shall  be 
provided  monthly.  (Refer  to  the  "MIS/Reports"  section  of  this  RFP  for  a  more  detailed 
discussion.) 


(4.11.10)  Ad  Hoc  Special  Noticing  Populations 

The  Vendor  must  provide  the  capability  to  generate  notices,  on  an  ad  hoc  basis,  to 
populations  of  violators  based  on  criteria  established  by  the  City. 

For  example,  a  target  population  could  include  violators  who  have  a  minimum  dollar 
amount  outstanding  on  their  license  plate,  e.g.,  $1,000.  For  this  population,  the  City 
would  identify  additional  criteria  such  as  "issue  date  of  tickets  must  be  prior  to  a  certain 
date",  etc. 


(4.11.11)  On-Line  Access  to  Notice  Records 

Noticing  records  shall  be  efficiently  and  effectively  available  for  both  ticket  level  and 
license  plate  level  inquiries  and  shall  record  and  provide  the  mail  date(s)  and  types(s)  of 
notice  mailed. 

Noticing  records  shall  be  efficiently  and  effectively  accessible  for,  at  a  minimum, 
violation,  registration,  license  number  and  name  inquiries. 
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(4.11.12)  Computer  System  Notice  Scheduling.  Creation  and  Revalidation 


The  public  must  be  provided  accurate  and  up-to-date  information.  Further,  when  the 
public  have  questions,  it  is  critical  that  we  respond  in  an  efficient,  effective  and  timely 
manner.  The  design  of  the  system's  notice  scheduling,  creation  and  revalidation 
features  must  take  into  consideration  the  staffing  and  capacity  constraints  that  impact 
our  public  inquiry  operation.  The  following  requirements  have  been  developed  to 
enhance  our  ability  to  deliver  maximum  levels  of  customer  service. 

Notice  of  Overdue  Violations  and  Impending  Registry  Non-Renewal  (ORN)  Notices  for 
Massachusetts  registrants  shall  be  created,  or  revalidated  if  previously  created,  on  a 
daily  basis  within  24  hours  of  the  printing  of  the  notices  so  as  to  provide  valid,  accurate, 
up-to-date  information.  The  daily  creation  or  revalidation  of  these  ORN  Notices  shall 
normally,  at  a  minimum,  occur  four  different  days  a  week;  three  of  those  minimum  four 
days  must  include  Monday,  Tuesday,  Wednesday,  and/or  Thursday. 

Overdue  Violation  Notices  for  out-of-state  registrants  shall  be  created,  at  a  minimum, 
on  a  once-a-week  basis,  within  24  hours  prior  to  their  printing;  or  revalidated,  if 
previously  created,  within  24  hours  prior  to  their  printing. 

All  other  ticket  level  notices  shall  be  created  on  a  once-a-week  basis  within  24  hours 
prior  to  their  printing;  or  revalidated,  if  previously  created,  within  24  hours  prior  to  their 
printing. 

Seizure  Notices  shall  be  created  on  a  bi-weekly  basis  within  24  hours  prior  to  their 
printing;  or  revalidated,  if  previously  created,  within  24  hours  prior  to  their  printing. 

All  other  plate  level  notices  typically  shall  be  created,  on  a  monthly  basis  within  24 
hours  prior  to  their  printing;  or  revalidated,  if  previously  created,  within  24  hours  prior 
to  their  printing,  on  a  once-a- month  basis. 

In  the  process  of  creating  notices,  especially  ticket  level  notices,  the  Vendor  shall 
ensure  that  those  tickets  with  the  earliest  eligibility  dates  are  created  first.  Also,  mail 
dates  shall  be  scheduled  close  to  a  ticket's  date  of  notice  eligibility. 

Other  noticing  routines  for  special  notices  or  special  collection  efforts  shall  be  based 
solely  upon  the  discretion  of  the  City. 

Scheduling  and  creation  of  notices  shall  be  performed  by  the  Vendor  as  normal  and 
routine  procedure.  An  established  schedule  shall  be  provided  for  each  notice  type  and 
shall  be  approved  by  the  City.  This  schedule  shall  be  based  upon  timetables  such  as: 
the  same  day  of  the  week,  the  same  date  of  the  month,  each  weekend  of  the  month,  etc. 
For  example: 

Scheduling  and  creation  shall  utilize  City  approved  quantity  parameters  for  number  of 
tickets  and/or  number  of  plates  to  be  noticed  on  a  daily,  weekly,  monthly  or  other  basis. 
Typically,  volume  limits  would  apply  primarily  to  ORN's  and  Overdue  Notices, 
however,  this  capability  is  required  for  all  notices. 

Notices  that  are  created  through  the  On-Line  Special  Collections  Notice  System 
component  shall  be  generated  and  run  prior  to  the  start  of  the  business  day  following  the 
date  of  data  input. 
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(4.11.13)  Notice  Printing 


Notices  shall  be  printed  according  to  a  schedule  that  is  similar  to  the  scheduling  and 
creation  of  notices.  For  example,  daily  notices  shall  be  routinely  printed  on  a  daily 
basis,  as  normal  operating  procedure.  Weekly  notices  shall  be  routinely  printed  on  a 
weekly  basis,  etc. 

Notices  shall  be  printed  within  twenty-four  (24)  hours  of  their  creation,  or  within 
twenty-four  (24)  hours  of  their  revalidation  if  previously  created. 

In  the  event  that  a  notice  is  created  or  revalidated  during  a  weekend,  that  notice  shall  be 
printed  no  later  than  (as  early  as  possible)  on  the  following  Monday  morning  which  is 
defined  as  prior  to  12:00  Noon  of  that  Monday. 

Other  or  revamped  printing  routines  for  routine  or  special  notices  will  be  based  solely  at 
the  discretion  of  the  City. 

Unless  alternate  methods  can  be  utilized,  notices  shall  be  printed  in  a  manner  that 
allows  for  zip  code  or  other  sorting  and  processing  that  produces  optimal  postage  cost 
savings,  e.g.,  "Zipcode  +  4  Presort",  "Zipcode  Presort",  zipcode  bar-coding,  etc. 

Further,  as  normal  and  routine  procedure,  the  Vendor  shall  provide  for  the  timely  and 
accurate  printing  of  notices  through  the  utilization  of: 

one-part,  continuous-form,  standard  size  "statement  style"  notices,  e.g.,  Overdue 
Notice  (currently  in  a  "2-up"  format); 

multiple-part,  continuous-form,  specialty  size  "statement  style"  notices,  e.g., 
Seizure  Notice  (currently  in  a  "2-up"  format); 

one-part,  continuous-form,  "letter  size"  notices; 

window  envelopes. 

The  printing  of  notices  shall  be  conducted  and  organized  in  a  manner  that  ensures  on- 
going and  consistent  maximum  quality  control  for  the  pre-printing,  actual  printing  and 
post-printing  stages  of  the  printing  functions. 
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(4.11.14)  Information  to  be  Printed  on  the  Notices 

At  a  minimum,  the  following  data  and  information  shall  be  provided  for  and  printed  on 
notices: 

Data  from  the  actual  ticket  which  currently  includes  ticket  number,  state  of 
registration,  registration  number,  date  of  violation,  time  of  violation,  name  of 
violation,  location  of  violation  and  fine  amount 

Registrant's  name  and  address  including  zip  codes  (9  digit  zip  codes  when 
available) 

Late  penalties  and  non-renewal  fees  for  each  specific  ticket  on  the  notice 
Payment  Received 

Status  code  including  Non-renewal,  Collection  Agency,  and  Seizure  Eligible 
(for  Seizure  Notices) 

OCR  Scan  Line  with  ticket  number,  amount  due  on  the  ticket  and  City  numeric 
code 

Mail  date  of  the  notice 

Notice  number  that  is  unique  and  links  to  specific  tickets  appearing  on  the  notice 
Amount  due  for  each  specific  ticket 
Amount  due  for  all  the  tickets  on  the  notice 


As  previously  discussed,  the  utilization  of  OCR  Scan  Lines  may  be  contingent  upon 
certain  variables,  such  as  the  size  dimensions  of  a  notice.  Also,  for  ad  hoc  or  certain 
"letter  style"  notices,  certain  information  such  as  "location  of  violation"  may  not  be 
required. 


(4.11.15)  Notice  Registers 

Upon  the  generation  or  printing  of  a  notice  run,  the  Vendor  shall  generate,  maintain  and 
utilize  for  quality  assurance  purposes  a  notice  register  which  shall  list  all  notice  records 
and  data  elements  included  in  the  notice  run  in  addition  to  summary  plate,  notice, 
violation  and  dollar  amount  due  data.  On  occasion,  the  City  shall  require  duplicate 
registers  to  be  provided  to  the  City. 
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(4.11.16)  Mail  House  Function 


In  addition  to  the  generation  and  printing  of  notices,  the  Vendor  shall  be  responsible  for 
the  timely  mailing  of  all  notices.  Notices  shall  be  delivered  for  mailing  to  the  U.S. 
Postal  facility  no  later  than  twenty-four  (24)  hours  after  the  printing  of  the  notices. 

The  mailing  of  notices  shall  include,  but  not  be  limited  to,  the  following  mail  house 
functions: 

pick-up/retrieval  of  printed  notices,  forms,  etc.; 

"bursting"  forms,  folding  notices,  inserting  notices  into  mailing  envelopes, 
inserting  return  envelopes  into  mailing  envelopes,  enclosing  inserts  (if 
applicable),  sealing  envelopes; 

segregation  or  maintenance  of  notices  by  zip  code  or  other  sorting  procedures  in 
accordance  with  U.S.  Postal  System  specifications  for  zip-sort  cost  savings; 
transportation  of  notices  to  the  U.S.  Postal  System  facility; 

maintenance  of  stock  of  outgoing  and  return  envelopes  and  other  material 
shipped  by  the  Printer. 

The  Vendor  shall  be  responsible  for  complying  with  all  requirements  and  specifications 
for  first-class  permit  mail  as  set  forth  in  the  U.S.  Postal  System  "Domestic  Mail 
Manual"  document. 

The  Vendor  shall  be  responsible  for  presenting  and  maintaining  U.S.  Postal  receipts  for 
all  notices  mailed.  The  Vendor  shall  also  provide  various  management  reports  that  may 
be  required  by  the  City  for  reconciliation  and  audit  purposes. 

The  Vendor  must  satisfy  timely  turnaround  requirements  relating  to  the  pick-up  and 
delivery  of  notices  and  actual  mailing  of  notices  prior  to,  or  on,  the  mail  date  reflected 
on  the  notices. 

The  Vendor  must  provide  comprehensive  quality  control  at  the  Mail  House  to  ensure 
that,  among  other  things:  all  notices  that  are  printed  are  mailed;  all  notices  are  mailed 
according  to  schedule;  the  correct  envelope,  notice,  insert,  etc.  are  used,  and;  wastage  of 
envelopes  and  other  items  is  minimized. 
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(4.11.17)  Location  of  the  Notice  Generation/Printing  and  Mail  House  Functions 

The  City  presently  maintains  its  Mail  Permit  Account  at  an  out  of  state  location.  The 
City  has,  for  many  years,  had  the  location  be  at  a  Downtown  Boston  location.  This 
arrangement  has  provided  for  direct,  efficient  and  effective  delivery  of  funds  by  the  City 
to  its  permit  account  and  interface  with  regional  customer  service  and  postal  permit 
account  personnel.  This  arrangement  has  also  provided  for  the  imprinting  by  the  Post 
Office  of  the  'Boston'  origin-of-mailing  postmark  (which  is  desirable  given  that  notices 
are  'mailed'  by  the  City  of  Boston).  In  addition,  on  occasion  other  City  departments 
utilize  the  BTD/OPC's  permit  account  for  large  mailings.  (For  these  other  departments, 
post  office  location  is  important.)  Further,  the  City  has  been  very  satisfied  with  the 
quality  of  performance  of  this  facility. 

In  consideration  of  the  above  factors,  the  City  believes  that  its  business  interests  would 
best  be  served  by  the  continued  utilization  of  the  South  Station  Annex  facility  as  the 
location  of  its  postal  account.  If  this  cannot  not  be  accomplished  the  Vendor  must 
explain  this  in  writing. 

In  further  consideration  of  the  above  factors  as  well  as  overall  quality  control/assurance 
considerations,  the  City  believes  that  it  is  reasonable  and  necessary  to  require  that  the 
Vendor's  notice  generation/printing  and  mail  house  functions  be  located  at  an 
operationally  convenient,  efficient  and  effective  distance  from  the  South  Boston  Annex 
facility,  the  Vendor's  Boston  office  and  City  Hall. 

While  the  City  does  recognize  that  varying  technological  or  other  solutions  relating  to 
the  provision  of  the  printing  and  mail-house  functions  may  provide  for  an  alternate- 
location-argument,  any  such  argument  would  have  to  be  advanced  in  the  context  of  the 
above  specific  set  of  circumstances  that  serve  to  define  the  City's  needs. 

In  the  event  that  a  prospective  Vendor  proposes  to  locate  the  above  mentioned  functions 
substantially  outside  of  the  City's  boundaries,  the  prospective  Vendor  shall  completely 
satisfy  the  City  that  its  solution  will  accommodate  logistical  considerations  and  high 
quality  assurance  standards  and/or  that  alternative  postal  facility  locations  will  not 
undermine  or  negatively  effect  the  above-mentioned  interests  of  the  City. 

Prospective  Vendors  that  propose  alternative  location  arrangements  shall  be  fully 
cognizant  of  and  accommodate  transportation  costs  and  all  logistical  considerations  as 
they  relate  to  the  possible  inter-relationships  of  the  print,  mail  house,  post  office  and 
other  functions.  Also,  they  shall  fully  consider  and  accommodate  any  issues  relating  to 
the  establishment  and  maintenance  of  efficient  and  effective  quality  assurance.  Further, 
they  shall  be  aware  of  and  accommodate  logistical  and  other  considerations  relating  to 
the  release  from  Printed  Material  inventory  of  notice  stock  (for  printing)  and  envelope 
stock  (for  mailing). 
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(4.11.18)  Inventory  Control 


The  Vendor  shall  be  responsible  for  related  materials  inventory  management  and  shall 
be  responsible  for  communicating  inventory  replenishment  requirements  directly  with 
the  forms  printer. 


(4.11.19)  OCR  Processability 

The  Notice  System  printing  function  shall  accommodate  optical  character  recognition 
(OCR)  technology  that  shall  be  utilized  in  payment  processing  to  minimize  payment 
processing  time  and  payment  processing  operator  errors. 

At  a  minimum,  OCR  payment  processing  must  be  utilized  for  all  ticket  level  notices. 
Further,  the  ticket  number,  amount  due,  and  (if  applicable)  city  code  data  contained  on 
ticket  level  notices  must  be  OCR-readable. 

OCR  technology  and  processing  shall  also  be  utilized  for  returned  mail  processing  (see 
the  "Nixie"  Program  described  in  this  section).  At  a  minimum,  returned  mail 
processing  (Nixies)  shall  be  utilized  for  the  Overdue  Notice. 


(4.11.20)  Returned  Mail  -  Bad  Address  System  (Nixies) 

In  order  to  minimize  postage,  forms  and  envelope  costs,  the  Vendor  must  provide  for 
the  cessation  of  notice  activity  for  a  particular  registrant  when  a  mailing  address  for  that 
registrant  is  determined  to  be  no  longer  valid. 

In  the  event  that  an  Overdue  Notice  (which  is  currently  the  only  notice  utilized  as  part 
of  this  application)  or  any  other  notice  specified  by  the  City  is  mailed  to  an  address 
provided  by  the  RMV  and  is  returned  by  the  Post  Office  as  undeliverable  (e.g., 
forwarding  address  expired,  etc.),  the  Vendor  shall  notate  the  database  via  OCR 
processing  of  this  information. 

Such  notation  shall  be  displayed  on-line  on  primary  inquiry  and  plate  detail  related 
screens. 

In  addition,  upon  notation  of  the  database  the  Vendor  shall: 

exclude  certain  notice  types  from  being  generated  for  the  notated  ticket  and 
other  tickets  charged  to  the  registration,  and/or 

allow  certain  notice  types  to  be  generated  for  the  notated  ticket  and  other  tickets 
charged  to  the  registration, 

allow  non-renewal  'mark'  transactions  to  be  generated  for  the  notated  ticket(s) 
and  other  tickets  subsequently  assigned  to  the  affected  plate. 
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For  example,  the  City  may  specify  that  all  notices  except  the  Seizure  Notice  be 
excluded  from  mailing  to  the  'bad  address',  or  that  only  plate  level  notices  or  a 
combination  of  certain  plate  level  notices  be  generated  and  mailed. 

Upon  the  receipt  of  a  new/updated  address  from  the  RMV,  or  from  some  other  source 
approved  by  the  City  (e.g.,  the  U.S.  Postal  System),  the  Vendor  shall  resume  noticing  of 
previously  excluded  violations. 

Further,  upon  request  the  Vendor  shall  produce  a  report  listing  the  name,  address  and 
registration  of  all  nixed  plates.  The  City  shall  utilize  this  report  to  instruct  the  Vendor 
to  remove  the  nixie  status  from  specific  registrations. 


(4.11.21)  Notice  Management  System 

The  Vendor  shall  provide  an  integrated,  on-line  Notice  Management  System  which 
shall  provide  comprehensive  reporting  of  notice  activity. 

The  Notice  Management  System  shall  be  organized  according  to  notice  type. 

For  each  notice  run,  this  system  shall  provide  summary  data  which  shall  include  at  a 
minimum: 

-  the  date  of  notice 

-  the  number  of  notices  mailed 

-  the  number  of  license  plates  noticed 

-  the  number  of  tickets  noticed,  and 

-  the  total  dollar  amount  of  each  notice  run. 

This  system  shall  provide  a  scrolling  function  to  allow  efficient  and  effective  ease  of 
movement  between  notice  type  screens. 

The  system  shall  also  provide  direct  inquiry  access  for  a  specific  notice  type  and  date  of 
mailing  of  a  specific  notice  type. 

In  regard  to  'date  of  mailing',  the  Notice  Management  System  shall  provide  all  noticing 
data  and  information  for,  at  a  minimum,  notice  activity  within  the  preceding  twelve 
months.  However,  since  current  data  will  more  routinely  be  utilized,  the  system  shall 
accommodate  the  presentation  of  more  current  activity  (e.g.,  the  preceding  three 
months)  within  the  scrolling  or  search  function. 

The  system  shall  also  provide  direct  inquiry  access  from  a  scrolling  screen  to  an 
individual/particular  registration  and  driver's  license  inquiry  screen  (record). 

Notice  counts  and  data  shall  be  posted  to  the  Notice  Management  System  prior  to  the 
notice  mail  date.  However,  in  posting  the  data  relating  to  a  particular  notice  type's  mail 
date,  in  the  event  that  the  data  is  revalidated  then  the  Vendor  shall  post  the  revised  data. 
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(4.11.22)  Notice  Log 


The  Vendor  shall  maintain  a  hard  copy  notice  log  for  all  notice  activity. 

The  notice  log  shall  be  organized  by  generation  date  of  notice  and  shall  contain,  at  a 
minimum,  the  following  information  for  each  notice  type: 

-  mail  date  of  notice 

-  date  notice  sent  to  the  mail  house 

-  date  notice  sent  to  the  post  office 

-  number  of  notices 

-  number  of  tickets 

-  comments  (if  applicable) 

-  control  or  reference  numbers,  etc. 

This  log  shall  be  provided  to  the  City  on  a  monthly  basis  and  shall  also  include  summary 
information  for  the  number  of  notices  generated  and  mailed  for  each  notice  type. 
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4.12 

BOOT  AND  TOW  SYSTEM 
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(4.12)  BOOT  AND  TOW  SYSTEM 


(4.12.0)  On-Line.  Real-Time  and  Comprehensively  Integrated  System 

The  Vendor  must  provide  an  on-line,  real-time  Boot  and  Tow  System.  The  Boot  and 
Tow  System  must  be  completely  and  comprehensively  integrated  with  all  systems, 
subsystems  and  system  elements  of  the  PVPMISS  that  are  set  forth  in  this  RFP. 

Payments  received  by  all  City  Hall,  Tow  Lot  and  Vendor  on-line  cashier  locations  shall 
be  immediately  reflected  in  this  System.  On-line  dispositions  and  suspend  transactions 
must  also  be  immediately  reflected  in  this  System. 

The  Boot  and  Tow  System  must  be  updated  immediately  following  all  batch  and  other 
transaction  update  cycles.  This  update  activity  shall  include  system  generated 
transactions,  such  as  the  application  of  late  penalties. 

The  Vendor,  through  its  provision  of  a  comprehensively  integrated  and  on-line,  real- 
time Boot  and  Tow  System,  must  effectively  and  efficiently  ensure  that  the  availability, 
integrity  and  accuracy  of  all  information  and  data  is  the  highest  degree  attainable  for 
this  important  and  highly  sensitive  function. 


(4.12.1)  Seizure  and  Violation  Tow  Components 

The  Boot  and  Tow  System  must  fully  support,  in  an  efficient  and  effective  manner,  two 
separate  programs:  (1)  the  Seizure  Program,  and  (2)  the  Violation  Tow  Program. 

Vehicle  registrations  are  eligible  for  seizure  due  to  outstanding  parking  violation  tickets. 
The  Vendor  must  accommodate  three  possible  seizure  scenarios.  They  are:  (1)  the 
placement  of  an  immobilization  device  (the  boot)  on  a  parked  vehicle;  (2)  the 
immediate  towing  of  a  vehicle  to  the  BTD  Tow/Impound  Lot;  and  (3)  the  booting  and 
subsequent  towing  of  a  vehicle. 

Vehicles  that  are  eligible  for  Violation  Tows  are  immediately  towed  to  the  BTD 
Tow/Impound  Lot.  Violation  Tows  result  when  a  vehicle  is  parked  on  a  key 
thoroughfare  during  prohibited  hours  or  otherwise  parked  in  a  manner  or  location  that  is 
determined  to  undermine  traffic  flow  and/or  public  safety. 


(4.12.2)  Abandoned  Vehicle  Program  Tow  Lot  Support 

In  addition  to  supporting  the  Seizure  and  Violation  Tow  programs,  the  City  desires  to 
utilize  the  Boot  and  Tow  System  to  accommodate  Tow  Lot  support  for  abandoned 
vehicles  'tow',  'disposal',  'trash',  and  'storage  fee'  requirements. 

Refer  to  the  'Abandoned  Vehicle  System'  section  ('Tow  Lot  Support'  subsection)  of  this 
RFP  for  a  complete  discussion  of  this  desired  support. 
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(4.12.3)  Violation  Tow  Eligibility  Criteria 


Vehicles  are  eligible  to  be  'violation  towed'  by  the  City  where  a  visual  determination  is 
made  by  City  staff  that  such  a  tow  is  warranted.  (A  ticket  is  issued  for  a  violation  tow.) 


(4.12.4)   Seizure  Eligibility  Criteria 

Vehicle  registrations  are  eligible  for  seizure  upon  accumulation  of  five  (5)  unpaid, 
uncontested  or  contested  and  reactivated  tickets  that  have  received  the  initial  late 
penalty. 

The  Boot  and  Tow  system  must  automatically  determine  those  vehicle  registrations  that 
are  eligible  for  seizure.  The  determination  of  seizure  eligibility  must  occur  for  two 
distinct  yet  interrelated  activities:  (1)  the  generation  of  a  seizure  notification  prior  to 
seizure  action;  and  (2)  the  subsequent  placement  of  a  registration  into  the  Boot  Book  / 
Boot  Eligible  File  for  actual  seizure. 

The  Boot  and  Tow  system  must  contain  comprehensive  eligibility  criteria  and  edits  and 
controls  of  the  type  set  forth  in  the  Notice  System  section  of  this  RFP.  These  types  of 
criteria  and  edits  also  apply  to  the  efficient  and  effective  determination  of  seizure 
eligibility.  For  example,  areas  such  as  registrant  data,  penalty  assessment,  suspend 
status,  notice  history,  etc.,  must  reflect  conditions  that  would  support  a  determination  of 
seizure  eligibility. 

In  addition  to  these  type  of  eligibility  criteria  and  edits  and  controls,  the  Boot  and  Tow 
System  must  contain  additional  comprehensive  eligibility  criteria,  edits  and  controls  so 
that  the  complete  range  of  generic  conditions  that  would  disqualify  and  qualify  a 
vehicle  registration  from/for  seizure  would  be  provided  for.  These  include: 

-  exclude  certain  plate  types  and  configurations; 

-  exclude  certain  name  and  addresses  (e.g.,  unmarked 
police  vehicles  registered  to  common  addresses); 

-  exclude  tickets  that  are  partially  paid; 

-  exclude  vehicles  that  have  previously  been  booted 
within  the  last  ten  (currently)  days; 

-  exclude  registrations  (undercover,  etc.)  that  are  identified  as  multi-owner 
communicated  to  the  Vendor  via  batch  reports. 

In  addition,  registrations  and  tickets  with  certain  MA.  RMV  name  and  address  error 
codes  (such  as  stolen  plate,  canceled  plate  or  expired  plate)  must  be  eligible  for  seizure 
action. 

The  Boot  and  Tow  System  must  provide  the  above  comprehensive  eligibility  criteria, 
edits  and  controls  for  both  Massachusetts  and  out-of-state  vehicle  registrations. 

For  out-of-state  vehicle  registrations  a  registrant  address  is  not  a  requirement  as 
notification  obligations  are  satisfied  through  communication  with  out-of-state 
Department  of  Motor  Vehicles  (see  Notice  Program  section).  Note:  the  omission  of 
out-of-state  registrant  address  data  for  seizure  eligibility  determination  should  not  be 
construed  as  diminishing  the  value  and  importance  of  this  key  data. 
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Boot  and  tow  eligibility  criteria  must  be  applied  on  both  a  ticket  and  plate  level  basis  in 
order  to  ensure  the  integrity  of  seizure  action. 

Due  to  the  dynamic  PVPMISS  environment,  vehicle  registrations  will  continuously 
move  above  and  below  the  basic  five  ticket  eligibility  requirement.  The  Boot  and  Tow 
System's  eligibility  criteria,  edits  and  controls  must  effectively  and  efficiently 
accommodate  and  reconcile  these  various  activities. 

The  Boot  and  Tow  System  must  accommodate  changes  or  modifications  to  eligibility 
criteria,  edits  and  controls  in  an  efficient  and  effective  manner  without  negatively 
impacting  existing  functionality. 


(4.12.5)  Boot  Eligible  File  /  Boot  Book 

Every  two  weeks,  the  Vendor  shall  generate  and  load  or  otherwise  update  in  a  fully 
automated  fashion,  to  the  mobile  telecommunications  hand-held  devices  and  license 
plate  recognition  system  utilized  with  the  Seizure  Identification  System,  a  list  of  all 
vehicle  registrations  that  are  eligible  for  seizure.  Refer  to  Section  (4.12.19)  'Portable 
Seizure  Identification  Devices'  and  Refer  to  Section  (4.12.20)  'License  Plate 
Recognition  System'  for  a  complete  discussion  of  this  requirement. 

Every  two  weeks,  the  Vendor  shall  generate  and  provide  approximately  6  copies  of  a 
user-friendly  list  (Boot  Book)  of  all  vehicle  registrations  that  are  eligible  for  seizure. 
The  list  will  be  utilized  by  the  City  Boot  and  Tow  field  personnel  to  identify  vehicles 
for  seizure  and  shall  be  in  an  alphabet-numeric  order  format  according  to  state  and  on  8- 
1/2"  x  11"  paper,  with  'perfect  binding'.  This  list  shall  also  contain,  at  a  minimum, 
summary  license  plate  volume  and  dollar  amount  information  by  state  and  total. 

The  current  Boot  Book  format  is  available  for  review. 


(4.12.6)  Violation  Time  and  Location  Boot  File 

At  time  intervals  to  be  defined  by  the  City,  the  Vendor  shall  generate  and  provide  a 
Boot  File  that  is  formatted  and  driven  according  to  time  and  location  of  violation 
issuance  so  as  to  specifically  target  boot  eligible  violators  with  large  numbers  of 
outstanding  tickets.  This  boot  file  will  be  an  "intelligent"  list  of  violators  in  order  to 
pinpoint  and  hone  the  Scofflaw  trends,  habits  and  where  and  when  they  will  most 
frequently  be,  based  on  their  prior  ticket  history.  This  might  encompass  sorting  and 
filtering  by  time  periods  of  the  day,  days  of  the  week  and  other  related  information  and 
fields  to  facilitate  identifying  and  capturing  scofflaws. 


(4.12.7)  Seizure  Notices  and  Coordination  with  Boot  Book 

The  Vendor  shall  generate  bi-weekly  Seizure  Notices  as  specified  in  the  Dunning 
Notice  System  section  of  this  RFP. 

The  Vendor  shall  be  responsible  for  the  scheduling  coordination  of  seizure  notices  and 
the  boot  eligible  file  /  boot  book  so  as  to:  (a)  comply  with  the  law  which  requires  the 
mailing  of  a  Seizure  Notice  at  least  ten  days  prior  to  seizure  action,  and  (b)  optimize  the 
availability  of  seizure  eligible  registrations  for  City  boot  crews. 
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(4.12.8)  Manual  Entry  of  Seizure  Eligibility 


The  Boot  and  Tow  System  must  be  able  to  accommodate  the  efficient  and  effective 
manual  entry  of  seizure  eligibility  by  designated  City  staff  for  instances  where  a  vehicle 
registration  is  boot  eligible  but  the  registrant's  name  and  address  has  not  been  provided 
through  normal  interface  with  the  MA  RMV. 

Upon  the  entering  of  a  unique  transaction  code,  preferably  via  the  On-Line  Claims 
Processing  System,  the  Boot  and  Tow  System  shall  subject  the  registration(s)  in 
question  to  the  same  boot  eligibility  criteria  as  license  plates  that  are  automatically 
determined  to  be  boot  eligible,  except  that  name  and  address  eligibility  requirements  do 
not  apply. 

Upon  completion  of  data  and  instructions  entry,  the  Vendor's  system  shall  automatically 
generate  an  on-line  correspondence  style  Seizure  Notice  to  the  registrant. 


(4.12.9)  User-Friendly  On-Line  Data  Entry  and  Inquiry  —  Access  Screens 

The  on-line  data  inquiry  of  all  boot  and  tow  statuses,  activities  and  events  must  be 
provided  to  all  customer  service  personnel  in  a  user-friendly  and  operationally 
convenient,  efficient  and  effective  manner.  These  requirements  as  they  relate  to 
computer  access  screens  are  largely  set  forth  in  the  section  of  this  RFP  entitled 
'Required  Screen  Data'. 

For  'Dispatcher  and  Boot  Crew  /  Tow  Crew  /  Hearing  Support'  (described  on  the 
immediately  following  pages),  the  on-line  data  inquiry  and  data  entry  of  all  boot  and 
tow  statuses,  activities  and  events  must  also  be  provided  in  a  user-friendly  and 
operationally  convenient,  efficient  and  effective  manner.  Toward  this  end,  screen 
format  shall  accommodate  the  need  for  minimal  and  efficient  scrolling  routines  through 
the  consolidation  of  data  fields  on  screens.  For  example,  from  a  primary  single  screen, 
the  Tow  Lot  dispatcher  shall  be  able  to  (1)  authorize  and  (2)  confirm,  and  provide  all 
supporting  information  for:  a)  boot  action,  b)  boot  release  action,  c)  tow  action,  and  d) 
tow  release  action.  In  the  event  that  revisions  to  a  created  record  are  made  through  a 
sub-screen,  access  to  this  screen  shall  be  direct  from  the  record  to  be  revised. 
Additional  screen  requirements,  for  example  for  the  'Inventory'  function,  are  explicitly 
and  implicitly  discussed  in  this  section. 
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(4.12.10)  Dispatcher  and  Boot  Crew  /  Tow  Crew  /  Hearing  Support 

The  Boot  and  Tow  System  must  fully  support  the  dispatch  and  field-crew  functions 
interface  and  all  the  statuses,  activities  and  events  therein.  These  statuses,  activities  and 
events  are  listed  below  and  (in  combination  with  the  described  data  elements)  shall 
comprise  the  data  fields  for  a  Boot  and  Tow  (seizure  and  Violation  Tow)  record. 

a)  A  determination  if  a  vehicle  registration  is  boot/tow  eligible  or  not  boot/tow 
eligible. 

b)  An  initial  authorization  action  originating  from  and  entered  by  dispatch 
once  a  field-crew  has  initiated  BOOT  action. 

c)  A  confirmation  that  BOOT  authorized  action  was  successful  and  the  capture 
of  transaction  data  that  includes:  number  of  tickets  outstanding  and  amount 
owed,  time,  ID  number  of  field  crew,  street  address  location,  vehicle  color 
and  make,  boot  device  number,  reason  code  and  miscellaneous  remarks. 

d)  An  initial  authorization  action  originating  from  and  entered  by  dispatch 
once  a  field-crew  has  initiated  TOW  action. 

e)  A  confirmation  that  authorized  TOW  action  was  successful  and  the  capture 
of  transaction  data  that  includes:  number  of  tickets  outstanding  and  amount 
owed,  date,  time,  reason  code,  ID  number  of  field  crew,  street  address 
location,  vehicle  color  and  make,  Tow  Lot  location,  reason  code  and 
miscellaneous  remarks. 

f)  An  authorization  to  release  a  BOOTED  vehicle  which  is  automatically 
generated  and  triggered  upon  payment  of  the  boot/tow  fee  or  which  is 
automatically  generated  and  triggered  upon  a  data  entry  notation  to  the 
System  that  the  outstanding  tickets  were  successfully  appealed  (or  a 
determination  that  the  vehicle  is  eligible  for  Administrative  Release). 

g)  A  confirmation  that  authorized  release  of  a  BOOTED  vehicle  was 
completed  and  the  capture  of  transaction  data  that  includes:  date,  time, 
reason  code,  cashier  or  other  ID  number,  and  amount  paid  on  released 
vehicle. 

h)  An  authorization  to  release  a  TOWED  vehicle  which  is  automatically 
generated  and  triggered  upon  payment  of  the  boot/tow  fee  or  which  is 
automatically  generated  and  triggered  upon  manual  data  input  to  the  System 
that  the  outstanding  tickets  were  successfully  appealed  (or  a  determination 
that  the  vehicle  is  eligible  for  Administrative  Release). 

i)  A  confirmation  that  authorized  release  of  a  TOWED  vehicle  was  completed 
and  the  capture  of  transaction  data  that  includes:  date,  time,  reason  code, 
cashier  or  other  ID  number,  and  amount  paid  on  a  released  vehicle. 

j)    A  system  generated  determination  that  no  payment/dismissal  action  has 
occurred  for  a  booted  vehicle  within  a  certain  time  period  (currently  three 
days)  following  boot  action  and  that  the  "aged  boot"  vehicle  must  be 
removed  (towed)  from  its  street  location. 
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k)  A  determination  that  a  booted  vehicle  has  unlawfully  "escaped"  a  boot 
device,  i.e.,  in  some  manner  the  device  was  forcibly  removed  from  the 
vehicle  and  tickets  and  fees  remain  outstanding. 

1)    A  determination  that  a  towed  vehicle  has  unlawfully  "escaped"  from  the 
Tow  Lot;  and 

m)  A  determination  that  a  vehicle  has  been  auctioned  as  a  result  of  non- 
retrieval  action  by  the  owner  and  the  capture  of  transaction  data  that 
includes:  date  of  auction  and  amount  the  vehicle  was  auctioned  for.  Note: 
auctions  are  administered  by  the  Police  Department  who  are  responsible  for 
the  tracking  and  reporting  of  auction  amounts. 

n)    A  field  for  recording  the  ticket  number  of  the  tow  vehicle  that  should  be 
capable  of  edits  and  eventually  linking  to  the  online  ticket  information. 

o)  Capability  of  marking/flagging  vehicles  that  have  bad/improper  registration 
in  the  tow  record  to  show  the  status  in  the  main  parking  management  system. 


(4.12.11)  Correction  and  Revision  Capability 

The  Boot  and  Tow  System  must  accommodate  on-line  revisions  that  must  be  made  in 
an  efficient  and  user-friendly  manner  to  an  original  (i)  Violation  Tow  or  (ii) 
seizure/boot  record.  Such  corrections/revisions  must  be  accommodated  up  until,  but  not 
including,  the  point  that  a  vehicle  is  released. 

In  addition  to  the  need  to  correct  any  possible  errors  or  add/revise  data,  the  Boot  and 
Tow  System  shall  be  flexible  so  as  to  accommodate  the  revision,  for  example,  of  a 
Violation  Tow  record  to  a  seized/booted  record.  (This  may  occur  in  the  event  that, 
upon  being  towed  to  the  Tow  Lot,  a  'Violation  Towed'  vehicle  may  be  discovered  to  be 
seizure/boot  eligible.) 

A  complete  history  of  the  original  transaction  data  must  be  maintained  and  must  be 
accessible. 

Once  a  boot  and  tow  record  has  been  corrected/revised,  the  System  must  clearly  and 
prominently  display  a  notation  of  said  action  for  all  subsequent  inquiries. 

On  a  daily  basis,  the  Boot  and  Tow  System  must  generate  audit  reports  for  revision 
activity  and  provide  the  date  and  time  of  a  revision,  the  ID  number  of  the  authorized 
staff  person  who  entered  the  correction  as  well  as  the  old  data  and  the  new  data  that  was 
entered. 
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(4.12.12)  Seizure  Fee  and  Violation  Tow  Fee 


Upon  confirmation  that  a  vehicle  has  been  seized  (booted  or  towed)  the  Boot  and  Tow 
System  must  immediately  assess  a  seizure  (boot)  fee  (currently  $56)  and  recalculate  the 
revised  total  amount  due  for  the  registration. 

Upon  confirmation  that  a  vehicle  has  been  Violation  Towed  the  Boot  and  Tow  System 
must  immediately  assess  a  Violation  Tow  fee  (currently  $90)  and  recalculate  the  revised 
total  amount  due  for  the  registration. 

Notwithstanding  the  correction  and  revision  capability  described  in  paragraphs  '4.12.11' 
above,  the  Boot  and  Tow  System  must  distinguish  between  (i)  boot/seizure  and  (ii) 
Violation  Tow  transactions  via  efficient,  effective  and  user-friendly  initial  data  input  (or 
by  other  such  means)  so  as  to  segregate,  and  prevent  fee  or  tracking  overlap  between, 
these  two  distinct  transactions.  At  present,  boot/seizure  vehicles  are  entered  and 
confirmed  as  a  matter  of  procedure  by  City  staff  as  'seized/booted'  before  any  tow 
activity  is  initiated.  Thereafter,  in  the  event  that  a  seized/booted  vehicle  is  subsequently 
towed  at  any  time  following  the  entering  and  confirmation  of  the  seizure/boot 
transaction,  the  PVPMISS  does  not  assess  the  $90  Violation  Tow  fee  to  the 
seized/booted  vehicle  which  was  towed. 

The  System  must  fully  track  and  report  on  seizure  fees  and  Violation  Tow  fees. 

The  Boot  and  Tow  System  must  accommodate  authorized  personnel  to  revise  /  correct 
the  $56  seizure  fee  and  the  $90  Violation  Tow  fee  to  a  zero  dollar  amount  upon 
completion  of  any  appeal  activity.  This  revision  function  must  be  on-line,  real-time  and 
a  history  of  the  original  and  revised  fee  amount  must  be  maintained. 


(4.12.13)  Storage  Fees 

For  a  vehicle  that  has  been  towed  to  the  Tow  Lot,  storage  fee  charges  must  begin  to 
accrue  immediately  (on  an  on-line,  real-time  basis)  upon  the  vehicle  being  recorded  as 
being  in  the  lot. 

The  (current)  rate  will  be  three  dollars  ($3)  per  hour  (or  fraction  thereof  an  hour)  to  a 
maximum  of  fifteen  dollars  ($15)  per  day.  The  storage  charges  will  be  calculated  for 
successive  days  by  the  same  formula,  reverting  to  the  hourly  rate  at  the  point  24  hours 
(or  multiple:  48,  72,  etc.)  after  arrival,  to  the  maximum  daily  charge  until  that  point  in 
time  that  the  vehicle  has  been  designated  as  released  (or  auctioned).  The  City  may 
require  that  a  maximum  time  period  during  which  storage  fees  can  be  assessed  be 
provided. 

The  System  must,  on  an  on-line,  real-time  basis,  recalculate  the  total  amount  due  for 
storage  fees  and  the  total  amount  due  (fees  and  tickets)  for  a  plate. 

The  System  must  track  and  report  on  storage  fees. 

The  Boot  and  Tow  System  must  accommodate  authorized  personnel  to  revise  /  correct 
storage  fees  to  a  zero  dollar  amount  or  to  an  amount  determined  upon  completion  of  any 
appeal  activity.  This  revision  function  must  be  on-line,  real-time  and  a  history  of  the 
original  and  revised  fee  amount  must  be  maintained. 
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(4.12.14)  Integration  With  Non-Boot  and  Tow  System  On-Line  Inquiry 


Except  for  the  initial  'authorization'  to  initiate  seizure  action,  the  previously  listed 
statuses,  events  and  activities  must  be  communicated  on-line,  real-time  to  all  customer 
service  and  public  inquiry  staff  via  the  prominent  display,  on  all  primary  inquiry 
screens,  of  messages  that  denote  the  status,  event  or  activity.  These  include  if  a  vehicle 
is:  boot/tow  eligible,  booted,  towed,  paid/dismissed  and  a  boot  release  is  scheduled, 
paid/dismissed  and  a  tow  release  is  scheduled,  aged  boot,  escaped  boot,  escaped  from 
Tow  Lot  and  auction. 

In  addition,  if  a  boot  eligible  license  plate  has  a  prior  affirmative  boot  escape  or  tow 
escape  in  the  historical  boot/tow  file,  the  Boot  and  Tow  system  must  provide  a  boot  or 
tow  escape  message  to  appear  in  conjunction  with  the  boot  eligibility  message. 

Further,  boot  eligibility  status,  specifically  the  number  of  boot  eligible  tickets,  must  be 
provided  on-line,  real-time  to  all  customer  service  and  public  inquiry  staff  on  all 
primary  inquiry  screens, 

The  provision  of  this  type  of  data  integration  is  required  so  as  to  optimize  the  delivery 
of  efficient  and  effective  public  inquiry  services  for  this  important  and  sensitive 
function. 

NOTE  REGARDING  SEIZED  /  BOOTED  /  TOWED  VEHICLE  NOTIFICATION: 

The  Vendor  shall  provide  the  capability,  upon  the  5th  day  of  vehicle  impoundment  (i.e., 
vehicles  that  have  been  towed  to  the  Tow  Lot  as  a  result  of  a  Seizure/Boot  or  a 
Violation  Tow)  to  automatically  generate  a  Vehicle  Notification  Letter  to  the  registered 
owner  of  said  vehicle,  so  informing  them  that  the  City  is  in  possession  of  the  seized  or 
towed  vehicle.  The  Vendor  shall  also  provide  the  capability  for  City  personnel  to 
manually  generate  such  Vehicle  Notification  Letters.  A  record  of  all  Vehicle 
Notification  Letters  shall  be  maintained  and  displayed  in  the  Vendor's  PVPMISS  and 
available  to  all  City  personnel  via  the  Boot  and  Tow  System  as  well  as  other  Customer 
Service  PVPMISS  screens  of  primary  interest  (i.e.,  Ticket  level  Data  Screen)  via  a  user 
friendly  efficient  and  effective  manner.  Letters  automatically  generated  and  manually 
generated  shall  be  separately  noted  in  the  Vendor's  system. 
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(4.12.15)  Boot  and  Tow  History 


The  Boot  and  Tow  System  must  provide  a  complete  history  of  past  and  current  boot  and 
tow  activities  and  transactions. 

History  information  must  be  provided  on-line,  real-time  through  the  PVPMISS'  primary 
inquiry  system.  History  information  must  reside  on-line  on  a  display  screen  that 
provides  key  plate-level  information,  such  as  license  and  registration  mark  information. 

Boot  and  tow  information  history  shall  contain  all  data  which  was  maintained  on  the 
active  file  and  shall  include:  activity  type,  fee  amount,  storage  amount,  auction  amount, 
date  of  activity,  fee  payment  amount  and  fee  payment  date  as  well  as  record  changes. 

These  historical  seizure  records  shall  remain  on  the  boot  and  tow  file  until  deletion  is 
authorized  by  the  City. 


(4.12.16)  Boot  and  Tow  Vehicle  Inventory  Function 

The  Boot  and  Tow  System  must  provide  an  on-line,  real-time  inventory  function  for:  (i) 
all  booted  vehicles  on  the  streets  and  (ii)  all  towed  vehicles  at  the  Tow  Lot. 

The  inventory  function  must  accommodate  inquiries  for  a  single  state/plate  and  for 
complete  listings  of  state/  plates  (preferably  for  a  minimum  of  10  per  screen).  Screen 
format  shall  also  allow  access  to  boot  and  tow  inventories  from  the  same  primary 
screen. 

For  booted  vehicles,  a  complete  and  separate  inventory  listing  must  be  maintained  in 
sequence  according  to  date  and  time  of  boot  application.  The  total  number  of  boots  on 
vehicles  (and  total  number  for  a  specific  variable)  shall  be  provided.  Also,  for  each 
vehicle,  this  list  must  maintain,  at  a  minimum,  the  following  information:  state  of 
registration,  registration  number,  date  of  boot,  time  of  boot,  location  of  booted  vehicle, 
make  and  color  of  vehicle,  boot  number,  crew  number  and  status. 

For  towed  vehicles,  a  complete  and  separate  inventory  listing  must  be  maintained  in 
sequence  according  to  date  and  time  of  tow.  The  total  number  of  towed  vehicles  at  the 
Tow  Lot  (and  total  number  for  a  specific  variable)  shall  be  provided.  Also,  for  each 
vehicle,  this  list  must  maintain,  at  a  minimum,  the  following  information:  state  of 
registration,  registration  number,  date  of  tow,  time  of  tow,  lot  location  of  vehicle,  make 
and  color  of  vehicle,  crew  number  and  status. 

When  the  inventory  function  is  utilized  to  determine  the  location  of  a  specific  vehicle 
the  primary  index  data,  i.e.,  state/plate,  is  often  not  available  as  motorists  forget  or  don't 
know  this  number.  Thus,  the  inventory  function  must  provide  record-indexing  through 
available  or  alternate  variables  which  include:  (a)  state  of  vehicle  registration,  (b)  make 
of  vehicle,  and  (c)  color  of  vehicle. 

The  Boot  and  Tow  System  inventory  function  must  allow  for  these  alternate  index 
variables  to  be  entered  separately  or  in  any  combination,  depending  upon  the 
availability  of  data  for  these  variables.  The  inventory  function  must  provide  on-line, 
real-time  listings  of  all  vehicles  that  match  one  or  any  combination  of  these  variables. 
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(4.12.17)  System  Security 


The  Boot  and  Tow  System  must  contain  comprehensive  and  user-oriented  security 
measures  to  help  ensure  that  access  to  the  system  is  restricted  to  authorized  users. 

Security  measures  must  accommodate  a  variety  of  specific  security  levels  that  would 
depend  upon  a  particular  staff  person's  responsibilities.  For  example,  one  level  of 
security  would  allow  inquiry  but  not  data  update.  In  addition,  security  levels  must  be 
provided  that  accommodate  access  to  combinations  of  the  activities  described  within 
this  section  of  the  RFP.  For  example,  one  level  of  security  may  provide  'boot 
authorization'  and  'boot  confirmation'  update  to  a  boot  record  but  would  not  allow 
access  to  the  'revision'  function. 


(4.12.18)  Vehicle  Impoundment  &  Immobilization  Management  Information  System 

The  Vendor  shall  provide  a  Boot  Management  Information  System.  Such  a  system 
must  include  as  a  minimum: 

a)  A  boot  eligible  file  /  boot  book  statistics  report; 

b)  track  the  number  of  boots  in  inventory  by  device  number; 

c)  the  boots  assigned  to  each  boot  crew; 

d)  inventory  of  booted  vehicles  in  lot  by  registration  number; 

e)  provide  an  aged  boot  report  for  the  prioritizing  of  towing;  and 

f)  identify  the  status  of  vehicles  which  have  been  booted. 


(4.12.19)  Portable  Seizure  Identification  Devices 

The  City  currently  utilizes  portable  hand-held  devices  to  identify  seizure  eligible 
vehicles.  The  Vendor  shall  be  required  to  provide  an  automated  seizure  system  and 
portable  hand-held  devices  for  this  purpose.  This  system  shall  provide  the  following 
features  and  functionality: 

The  portable  hand-held  devices  must  contain  all  vehicle  registrations  which  meet  the 
City's  criteria  for  seizure  eligibility; 

The  file  of  seizure  eligible  vehicle  registrations  must  be  culled  of  seized  vehicle 
registrations  on  a  daily  basis; 

The  Vendor  shall  refresh  the  file  of  seizure  eligible  vehicle  registrations,  currently  every 
two  weeks,  in  accordance  with  seizure  eligibility  criteria  discussed  previously  in  this 
section  of  the  RFP; 

The  System  shall  provide  the  maximum  number  of  user  friendly  and  operationally 
convenient  features  and  functions; 
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The  System  response  time  shall  be  fast  enough  to  allow  for  the  continuous  entry  of 
vehicle  registrations;  and  under  no  circumstances  shall  response  time  exceed  four  (4) 
seconds  for  data  retrieval  (i.e.,  query  against  "hit"  file  on  hand-held); 

The  System  shall  immediately  provide  a  visual,  via  prominent  screen  display,  as  well  as 
audible  message  upon  entry  of  a  vehicle  registration  contained  in  the  seizure  eligible 
file  residing  on  the  hand-held; 

The  System  shall  contain  sufficient  security  features  such  that  a  vehicle  registration 
entered  which  is  contained  in  the  seizure  eligible  file  residing  on  the  hand-held  cannot 
be  bypassed  ( i.e.,  not  booted)  without  supervisory  authorization; 

The  System  shall  retain  the  maximum  amount  of  activity  data  in  log  files  for  each 
unit/device;  This  data  shall  be  downloaded  to  a  local  pc  and  made  available  via  the 
maximum  amount  of  supervisory  reporting  programs; 

The  System  shall  provide  the  capability  for  supervisors  to  perform  field  audits  via 
viewing  log  file  data  contained  on  the  hand-held  unit; 

The  System  shall  accommodate  wireless  data  transfer; 

The  System  shall  provide  for  remote  access  to  the  management  features  of  the  system 
from  designated  pc  workstations  for  authorized  supervisors; 

The  hardware  and  software,  including  operating  system  and  programming  language, 
shall  be  such  that  these  system  "components"  shall  be  refreshed  as  significant 
improvements  become  available  and,  further,  the  implementation  of  such 
improvements  shall  not  adversely  affect  any  other  system  components,  features  or 
functionality.  Enhancements  shall  be  fully  tested  by  the  Vendor  and  shall  be  fully 
functional  in  a  production  environment  when  delivered. 

The  City  currently  utilizes  Symbol  model  9090  hand-held  units  for  this  application. 
The  hardware  proposed  for  this  application  shall  be  comparable  to  the  devices 
currently  in  production  in  terms  of  device  specifications  available  from  Symbol  for 
this  product  and  in  terms  of  features,  functionality,  durability,  user-friendliness,  and 
docking  procedures  for  upload  and  download  of  data  (including  bi-weekly  seizure  file 
refresh)  and  battery  charging.  The  Vendor  shall  provide  all  peripheral  equipment 
necessary  for  the  successful  operation  of  this  application  including  site  preparation, 
base  station  pc(s)  and  docking  stations  and  housing  necessary  for  the  secure  operation 
of  said  application.  Such  devices  shall  be  connected  to  the  minimum  number  of  base 
stations  necessary  for  the  simultaneous  upload/  download,  seizure  file  refresh  and 
charging  of  all  hand-held  devices  utilized. 

The  Vendor  shall  provide  a  minimum  of  twenty  (20)  hand-held  devices  in  good 
working  order  on  any  workday  and  five  (5)  units  available  at  the  Vendor's  local 
office,  fully  configured  and  in  good  working  order,  for  back-up  purposes.  The 
Vendor  shall  provide  sufficient  batteries  and  shall  maintain  a  sufficient  number  of 
fully  functional  back-up  batteries  at  the  Vendor's  local  office  for  use  with  such  hand- 
held devices  such  that  all  twenty  specified  devices  are  operational  and  in  good 
working  order  on  any  work  day. 
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The  Vendor  shall  provide  battery  chargers  and  docking  stations  for  each  device  used 
in  a  production  environment.  The  Vendor  shall  also  provide  a  battery  analyzer  and 
conditioner  for  use  with  the  batteries  utilized  with  the  hand-held  devices  proposed  for 
this  application. 

(4.12.20)  License  Plate  Recognition  Technology 

The  Vendor  shall  provide  a  minimum  of  three  (3)  license  plate  recognition  systems 
(LPRS),  including  all  system  hardware  and  communication  devices,  for  the  purpose  of 
scofflaw  identification,  parking  enforcement  and  parking  management  via  a  mobile 
patrol  vehicle.  The  Vendor  shall  be  responsible  for  the  installation  and  maintenance  of 
all  system  hardware,  communication  devices,  and  where  applicable,  any  vehicular 
modifications  necessary  to  accommodate  the  efficient  and  effective  performance  of  the 
vendors  License  Plate  Recognition  System.  The  Vendor's  LPRS  shall  be  capable  of 
accurately  matching  scanned  vehicle  license  plates  to  the  vendors  file  of  seizure  eligible 
registrations,  in  a  highly  efficient  and  effective  manner,  from  a  vehicle  traveling  no  less 
than  25  mph.  The  Vendor's  LPRS  shall  include  an  efficient  and  effective  touch  screen 
display  of  license  plates  scanned  and  audibly  and  visually  alert  vehicle  occupants  of 
registrations  scanned  which  are  contained  on  the  seizure  eligible  file.  The  file  of 
seizure  eligible  vehicle  registrations  must  be  culled  of  seized  vehicle  registrations  on  a 
daily  basis.  The  Vendor  may  be  required  to  provide  a  maximum  of  three  (3)  additional 
LPRS,  including  all  system  hardware  and  communication  devices,  for  additional  public 
safety  and/or  parking  management  initiatives.  The  City  shall  specify  installation 
locations  based  on  management  needs. 

The  Vendor  shall  refresh  the  file  of  seizure  eligible  vehicle  registrations,  currently  every 
two  weeks,  in  accordance  with  seizure  eligibility  criteria  discussed  previously  in  this 
section  of  the  RFP; 

The  System  shall  provide  the  maximum  number  of  user  friendly  and  operationally 
convenient  features  and  functions; 

The  System  response  time  shall  be  fast  enough  to  allow  for  the  continuous 
entry/scanning  of  vehicle  registrations;  and  under  no  circumstances  shall  response  time 
exceed  four  (4)  seconds  for  data  retrieval  (i.e.,  query  against  "hit"  file  on  hand-held); 

The  System  shall  immediately  provide  a  visual,  via  prominent  screen  display,  as  well  as 
audible  message  upon  entry  of  a  vehicle  registration  contained  in  the  seizure  eligible 
file  residing  on  seizure  eligible  database; 

The  System  shall  contain  sufficient  security  features  such  that  a  vehicle  registration 
entered  which  is  contained  in  the  seizure  eligible  file  residing  on  the  LPRS  cannot  be 
bypassed  ( i.e.,  not  booted)  without  supervisory  authorization; 

The  System  shall  retain  the  maximum  amount  of  activity  data  in  log  files  for  each 
unit/device;  This  data  shall  be  downloaded  to  a  local  pc  and  made  available  via  the 
maximum  amount  of  supervisory  reporting  programs; 

The  System  shall  provide  the  capability  for  supervisors  to  perform  field  audits  via 
viewing  log  file  data  contained  on  the  hand-held  unit; 
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The  System  shall  provide  for  remote  access  to  the  management  features  of  the  system 
from  designated  pc  workstations  for  authorized  supervisors; 

The  System  shall  accommodate  wireless  data  transfer. 

The  hardware  and  software,  including  operating  system  and  programming  language, 
shall  be  such  that  these  system  "components"  shall  be  refreshed  as  significant 
improvements  become  available  and,  further,  the  implementation  of  such 
improvements  shall  not  adversely  affect  any  other  system  components,  features  or 
functionality.  Enhancements  shall  be  fully  tested  by  the  Vendor  and  shall  be  fully 
functional  in  a  production  environment  when  delivered. 

The  City  may  desire  additional  features  and  functionality  relative  to  various  parking 
enforcement  and  management  initiatives  including,  but  not  limited  to:  resident  permit 
parking  enforcement,  time-based  parking  violation  enforcement,  photo  enforcement 
of  parking  violations,  turnover  studies,  stolen  vehicle  identification,  etc. . .  All  data 
shall  be  fully  integrated  with  the  Vendor's  core  parking  violation  system  as 
applicable.  The  Vendor's  LPRS  shall  accommodate  multi-tasking  capability  which 
shall  not  adversely  affect  any  other  system  components,  features  or  functionality. 

The  System  shall  be  capable  of  real  time  booting  and  real  time  system  updating  to  the 
boot  and  tow  system  (i.e.,  location  of  vehicle  booted,  vehicle  color  and  make,  boot 
number)  and  any  and  all  information  necessary  to  complete  a  boot  record  by  wireless 
cell  card  or  some  other  wireless  system. 

The  Vendor's  LPRS  shall  be  capable  of  reading  not  only  the  scofflaw  file  but  other 
LPR  applications  such  as  the  Resident  Parking  file,  the  Stolen  Vehicle  System,  and 
any  future  applications.  The  System  shall  be  capable  of  wireless  transmitting  an  e- 
mail  file  of  the  location  of  the  stolen  vehicle,  as  well  as  a  picture  of  the  plate  to  any  e- 
mail  address  programmed  into  the  system  without  operator  intervention.  The  System 
must  also  be  capable  of  doing  turnover  studies  and  live  booting  (i.e.  update  and 
search  the  system  by  way  of  a  wireless  system,  cell,  satellite,  and  so  forth  in  real 
time).  The  LPRS  Back  Office  System  shall  have  the  ability  to  store  and  catalogue 
photos  for  up  to  sixty  (60)  days  from  the  system  located  at  the  rear  gate  and  be 
capable  of  recalling  those  plates  on  demand  (search  by  Plate,  Street,  Location,  time 
and  date). 

A  third  LPR  System  is  to  be  located  at  the  tow  lot,  at  the  impound  lot  gate,  capable  of 
scanning  the  license  plates  of  vehicles  entering  and  exiting  the  lot  for  the  purpose  of 
tow  lot  inventory  control.  This  system  shall  be  capable  of  interacting  with  the  master 
parking  management  system  (Tow  and  Hold)  by  automatically  matching  and  time 
stamping  the  tow  record  upon  vehicle  arrival.  Such  data  shall  be  matched  to  vehicles 
exiting  the  lot  with  departure  time  recorded.  This  data  shall  be  retained  in  the 
Vendor's  Lot  Inventory  System  and  shall  produce  a  bar  code  inventory  control 
transaction  label  with  a  recognizable  transaction  number  and  license  plate.  The 
System  shall  have  the  capability  to  store  and  catalogue  photos  up  to  sixty  (60)  days. 
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The  LPR  System  shall  match  the  transaction  paid  at  any  cashiering  location  to  the 
license  plate  leaving  the  lot  and  confirm  the  vehicle  has  left  the  lot  in  the  system.  The 
System  must  also  be  capable  of  expansion  for  future  upgrades.  A  terminal  located  at 
the  entrance  of  the  impound  lot  shall  be  capable  of  reconciling,  reading  bar  codes, 
printing  bar  codes,  and  other  information  as  needed  on  a  form,  tag,  decal  or  other 
media  that  might  be  necessary. 
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4.13 

ABANDONED  VEHICLE  SYSTEM 
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(4.13)  ABANDONED  VEHICLE  SYSTEM 


(4.13.0)  On-Line.  Real-Time.  Integrated  System 

The  Vendor  must  provide  an  on-line,  real-time  Abandoned  Vehicle  System.  The 
Abandoned  Vehicle  System  shall  be  comprehensively  integrated  with  the  systems, 
subsystems  and  system  elements  of  the  PVPMISS  that  are  set  forth  in  this  RFP. 

Payments  received  through  the  On-Line  Cashier  System  shall  be  immediately  reflected 
in  this  System.  On-line  dispositions  and  suspended  transactions  shall  also  be 
immediately  reflected  in  this  System.  Also,  by  way  of  further  example,  the  'name'  of 
identified  violators  shall  be  accessible  from  the  same  'name'  access  or  menu  screen(s)  as 
for  parking  violations. 

The  vendor  must  also  provide  an  Abandoned  Vehicle  Reporting  System  whereby 
complaints  can  be  reported  by  the  City's  Mayor's  office  in  an  automated  fashion  to  the 
City's  BTD/Tow  Lot  personnel.  The  Vendor's  system  shall  allow  for  the  tracking, 
investigating  and  subsequent  reporting  back  to  the  Mayor's  Office  all  such  complaints 
and,  as  necessary,  the  transmission  of  data  for  creation  of  an  Abandoned  Vehicle 
Violation  Record  in  the  PVPMISS. 

AVRS  shall  be  made  to  be  fully  adaptable  to  communicate  to  other  applicable  systems 
either  the  Vendors  or  the  City's. 


(4.13.1)  Creation  of  Records  by  the  City 

The  Tow  Lot  shall  utilize  the  Vendor's  Abandoned  Vehicle  Reporting  system  to  create 
a  database  of  all  such  complaints.  This  database  shall  provide  the  Tow  Lot  personnel 
with  the  capability  to  create  a  "Pre-List"  of  all  complaints  grouped  by  Boston  Police 
District  as  a  function  of  the  Mayor's  office  reported-location  ward  and  precinct.  The 
system  shall  provide  the  capability  to  track  the  outcome  of  the  complaint  investigation 
and  entry  of  the  Abandoned  Vehicle  Report  (AVR)  ticket  data.  The  Vendor's  system 
shall  accommodate  multiple  vehicle  statuses  for  a  single  complaint. 

Upon  the  towing  of  an  abandoned  vehicle  to  the  Tow  Lot,  City  staff  persons  research 
vehicle  owner  data  via  the  'vehicle  identification  number'  (VIN). 

The  vehicle  owner  data  and  information  that  is  obtained  via  research  is  then  updated, 
along  with  data  and  information  from  the  AVR  ticket  and  data  from  Tow  Lot  staff,  by 
City  staff  to  the  vendor's  Abandoned  Vehicle  Reporting  System  in  order  to  create  an 
abandoned  vehicle  record. 

The  system  shall  be  capable  of  reporting  changing  status  of  records  for  tracking 
purposes. 

The  system  shall  correctly  assign  AVR  records  to  the  appropriate  Ward  and  Precincts 
and  the  appropriate  Boston  Police  Department  Areas  and  districts  by  the  street,  street 
number  and  location  supplied  by  the  city. 
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(4.13.2)  Creation  of  Records  by  the  Vendor 


The  above-mentioned  abandoned  vehicle  records  are  currently  sent  by  the  City  from  the 
Vendor's  Abandoned  Vehicle  Reporting  System  to  the  Vendor  for  update  to  the 
PVPMISS  via  file  transfer  from  a  City  personal  computer  to  the  Vendor's  MVS  dataset 
with  all  information  updated  within  24  hours. 

The  data  and  information  contained  on  these  records  shall  include,  at  a  minimum: 

-  violator  name 

-  violator  address 

-  violator  license  number 

-  violator  date  of  birth 

-  AVR  ticket  number 

-  Vehicle  Identification  Number  (20  character  minimum) 

-  date  of  violation 

-  location  of  violation 

-  vehicle  make 

-  vehicle  color  code 

-  registration  number  assigned  to  vehicle 

-  registration  number  on  vehicle  (if  available) 

-  Inspection  Sticker  date 

-  issuing  agent  badge  number 

-  Tow  Fee 

-  Tow  Fee  date 

-  Abandoned  Vehicle  Fee 

-  Trash  Fee 

-  Trash  Fee  date 

-  Disposal  Fee 

-  Disposal  Fee  date. 

This  data  and  information  shall  be  provided  to  the  Vendor  on  a  weekly  basis  and  shall 
be  updated  to  the  Abandoned  Vehicle  System  within  twenty-four  hours  of  receipt  by  the 
Vendor. 

The  update  of  this  information  shall  include  the  system  calculation,  by  the  Vendor,  of 
the  total  amount  due  via  the  addition  of  the  above-mentioned  fees. 

Also,  the  Abandoned  Vehicle  System  must  provide  for  an  Abandoned  Vehicle  Fee  date' 
data  element,  which  shall  automatically  be  assigned  the  same  date  as  the  above 
referenced  Abandoned  Vehicle  Ticket  date  of  violation. 

Further,  the  Vendor  must  efficiently  and  effectively  accommodate,  and  provide  on-line 
access  for,  all  additional  data  fields  and  elements  for  all  activities,  events  or  transactions 
that  relate  to  the  abandoned  vehicle  record.  These  include  the  areas  of  payments, 
notices,  RMV  dispositions,  Tow  Lot  activity  (e.g.,  'storage  fees'),  etc. 

This  data  is  currently  downloaded  weekly  for  the  purpose  of  the  Pre  List.  However  the 
system  shall  accommodate  ad-hoc  reporting  for  Pre-List  generation.  . 
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(4.13.3)  Screen  Format  and  On-line  Access  and  Integration  with  the  PVPMISS 

As  stated  on  the  previous  page,  "the  Vendor  must  efficiently  and  effectively 
accommodate,  and  provide  on-line  access  for,  all  data  fields  and  elements  for  all 
activities,  events  or  transactions  that  relate  to  the  abandoned  vehicle  record.  These 
include  the  areas  of  payments,  notices,  RMV,  dispositions,  Tow  Lot  activity  (e.g., 
'storage  fees'),  etc." 

Toward  this  end,  in  terms  of  screen  format,  the  City  desires  to  utilize  the  same  general 
format  as  that  set  forth  for  parking  tickets  in  the  'Required  Screen  Data'  section  of  this 
RFP. 

The  Abandoned  Vehicle  System  shall  be  integrated  with  the  Vendor's  PVPMISS  so  that 
on-line  access  to  abandoned  vehicle  records  is  operationally  convenient,  efficient  and 
effective.  Toward  this  end,  the  City  requires  that  on-line  access  be  conducted  from  the 
same  general  inquiry  screens  or  menu(es)  used  for  parking  violation  records. 

Immediately  upon  update  to  the  Vendor's  System,  the  Vendor  must  provide  for  on-line, 
real-time  inquiry  of  the  abandoned  vehicle  violation  record  by  City  staff  via,  at  a 
minimum,  the  AVR  ticket  number,  name  and  driver's  license  number.  (A  license  plate 
number  is  not  a  reliable  or  consistent  index  for  abandoned  vehicle  inquiries  and  shall 
not  be  utilized  for  this  purpose.) 

On-line  access  for  abandoned  vehicle  records  via  'AVR  ticket  number'  can  be  via  either 
through  the  user-  friendly,  efficient  and  effective:  (a)  provision  of  a  separate  menu  item, 
or  (b)  utilization  of  either  the  'registration  number'  or  '  ticket  number'  parking  ticket 
menu  (access)  fields. 

On-line  access  for  abandoned  vehicle  records  via  'name'  and  'driver's  license  number' 
can  be  via  either  through  the  user-friendly,  efficient  and  effective:  (a)  provision  of  a 
separate  menu  item(s),  or  (b)  utilization  of  either  the  'name'  or  'driver's  license  number' 
parking  ticket  menu  (access)  fields. 

Also,  on-line  access  for  abandoned  vehicle  records  via  'name'  and  'driver's  license 
number'  shall  accommodate  record  'collateralization'  functionality.  In  other  words,  all 
parking  ticket  related  registration  records  and  all  abandoned  vehicle  records  assigned  to 
the  same  entity  shall  be  automatically  combined  in  a  manner  that  provides  for:  (a) 
summary  viewing  of  a  list  of  said  records,  and  (b)  the  efficient  and  effective  (scrolling 
or  other)  access  to  each  individual  record. 
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(4.13.4)  Scheduling  of  Hearings  and  Hearings  Support 


The  Abandoned  Vehicle  System  shall  automatically  schedule  hearing  dates  and  times 
for  identified  violators. 

Standard  volume,  date  and  time  parameters  will  be  provided  by  the  City.  For  example, 
a  maximum  of  seventy-five  (75)  hearings  would  be  scheduled  for  each  Tuesday  and 
Thursday  of  each  week  and  all  hearings  for  those  days  would  be  scheduled  for  either  of 
two  (2)  times,  10:00  A.M.  or  2:00  P.M.  The  number  of  hearings  scheduled  shall  be 
proportional  for  each  of  the  two  time  periods. 

The  Vendor  shall  print  at  OPC  the  'Hearing  Disposition  Forms'  for  each  scheduled 
hearing  for  the  use  by  City  Hearing  Officers  at  the  hearings.  The  content  and  format  of 
the  'hearing  disposition  forms'  shall  be  specified  by  the  City. 

Hearing  dispositions  will  be  data  entered  on-line,  real-time  by  City  staff.  The 
Abandoned  Vehicle  System  must  accommodate  the  dismissal  of  all  fines  or  a 
combination  of  the  fines. 


(4.13.5)  Generation.  Printing  and  Mailing  of  Notices 

The  Abandoned  Vehicle  System  must  generate,  and  the  Vendor  shall  print,  insert  (along 
with  a  return  envelope)  and  mail  within  a  specified  time  period  prior  to  the  above- 
mentioned  hearing  date,  an  Abandoned  Vehicle  Notice  To  Appear'.  This  notice  shall 
inform  the  identified  violator  of  the  infraction  and  the  above-mentioned  hearing  date 
and  time  (in  addition  to  an  option  to  pay  the  violation  in  lieu  of  a  hearing). 

If  payment  in  full  is  not  made  or  if  complete  dismissal  is  not  effected  during  a  specified 
time  period  following  the  hearing  date,  the  Abandoned  Vehicle  System  shall 
automatically  generate,  and  the  Vendor  shall  print,  insert  (along  with  a  return  envelope) 
and  mail  an  Abandoned  Vehicle  Default  Notice'  that  informs  the  identified  violator  of 
pending  non-renewal  of  driver's  license  and/or  registration. 

These  notices  shall  be  in  letter  format  and  shall  include,  at  a  minimum,  the  following 
data  from  the  abandoned  vehicle  record: 

notice  date,  name  and  address,  AVR  ticket  number,  Vehicle  Identification 
Number  (VIN),  registration  number  (if  available),  vehicle  make,  vehicle  color, 
location  of  violation,  violation  date  and  total  amount  due. 

The  required  format  and  content  of  the  above  notices  are  contained  in  the  'Notice 
Program'  document. 

The  Vendor  may  also  be  required  to  generate  notices  upon  the  confirmation  of  non- 
renewal action  by  the  RMV. 

Within  twenty-four  hours  of  the  generation  of  the  above  notices,  the  Vendor  shall 
provide  to  the  City  a  'Notice  Register'  that  lists  the  data  pertaining  to  each  of  the  notices 
generated  and  mailed  as  well  as  summary  counts  and  amounts.  The  records  appearing 
on  these  registers  shall  be  organized  by  AVR  ticket  number.  For  the  'Notice  To  Appear' 
notice,  said  register  must  also  be  organized  according  to  hearing  date  and  time. 
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(4.13.6)  Payment  Processing 


Payment  processing  will  typically  be  handled  by  the  City  and  payments  will  be  directed 
to  the  City  via  'return  envelopes',  etc. 

Payment  processing  shall  be  conducted  via  the  On-Line  Cashier  System.  The  Vendor's 
PVPMISS  must  accommodate  the  efficient  and  effective  processing  of  complete  and 
partial  abandoned  vehicle  payments. 


(4.13.7)  Revisions  to  Vehicle  Owner  Name  and  Address 

Frequently,  registrants  initially  identified,  as  owners  of  abandoned  vehicles  will  provide 
the  City  with  the  name  and  address  of  an  individual  or  entity  to  whom  they  sold  their 
vehicle  prior  to  the  incidence  of  vehicle  abandonment.  A  vehicle  may  change  hands 
numerous  times  in  private  sale  transactions  prior  to  abandonment.  Therefore,  the 
Abandoned  Vehicle  System  must  allow  for  the  overlay  of  a  new  name  and  address  over 
an  existing  (initial  or  overlaid)  name  and  address.  At  present,  such  revisions  are 
processed  on-line  by  the  City. 

All  overlaid  names  and  addresses  must  remain  in  the  system  in  a  name  and  address 
history  file,  preferably  the  same  file(s)  as  that  used  for  parking  tickets. 

Upon  the  identification  of  a  revised  vehicle  owner,  the  Abandoned  Vehicle  System  shall 
schedule  and  generate  the  above  described  hearing  and  notices. 

Within  twenty-four  hours  of  the  generation  of  the  above  notices,  the  Vendor  shall 
provide  to  the  City  a  'Notice  Register'  that  lists  the  data  pertaining  to  each  of  the  notices 
generated  and  mailed  as  well  as  summary  counts  and  amounts.  The  records  appearing 
on  these  registers  shall  be  organized  by  AVR  ticket  number.  For  the  'Notice  To  Appear' 
notice,  said  register  must  also  be  organized  according  to  hearing  date  and  time. 


(4.13.8)  Non-Renewal  of  Driver's  License  and/or  Registration 

At  this  time  the  City  does  not  anticipate  the  need  to  conduct  non-renewal  interface  with 
the  RMV  for  abandoned  vehicle  violations.  However,  such  interface  may  be  required  at 
a  later  date  in  time. 


(4.13.9)  Tracking  of  Repeat  Violators 

The  law  regulating  penalties  for  abandoned  vehicles  states  that  "whoever  abandons  a 
motor  vehicle  ...  shall  be  fined  two  hundred  and  fifty  dollars  [$250]  for  the  first  such 
abandonment  and  five  hundred  dollars  [$500]  for  each  such  abandonment  thereafter." 
Note:  the  amount  in  question  refers  to  the  Abandoned  Vehicle  Fine'  data  element 
described  earlier  in  this  section. 

The  Abandoned  Vehicle  System  must  accommodate  this  provision  of  the  law  and  shall 
count  and  track  the  number  of  separate  occurrences  of  vehicle  abandonment  by  the 
same  individual  or  entity  so  that  the  System  will  automatically  assess  the  correct  fine 
amount  for  any  abandoned  vehicle  record  submitted  to  the  Vendor. 
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The  law  also  provides  that: 

if  the  owner  has  abandoned  a  motor  vehicle  or  vehicles  on  three  occasions  ... 
each  subsequent  abandonment ...  shall  result,  in  the  case  of  a  person,  in  the 
revocation  for  one  year  of  the  owner's  license  to  operate  a  motor  vehicle,  and  in 
the  case  of  an  entity,  in  the  revocation  for  one  year  of  the  owner's  license  or 
permit  to  operate  a  business  pertaining  to  the  towing,  storing,  servicing  or 
dismantling  of  motor  vehicles  including  automobile  graveyards  and  junkyards. 

The  Abandoned  Vehicle  System  must  accommodate  this  provision  of  the  law  and  shall 
count,  track  and  report  on  the  number  of  separate  occurrences  of  vehicle  abandonment 
that  exceeds  three  by  the  same  individual  or  entity  so  that  the  City  can  initiate  the 
above-mentioned  suspension  action  wherever  possible.  The  City  will  specify  the 
frequency  and  timing  of  these  reports. 


(4.13.10)  Tow  Lot  Support 

As  previously  explained  in  this  section,  the  Vendor's  Abandoned  Vehicle  Reporting 
System  is  used  to  coordinate  the  activities  of  City  tow  crews  in  the  towing  of  abandoned 
vehicles. 

However,  as  stated  in  the  'Boot  and  Tow  System'  section  of  this  RFP  (Abandoned 
Vehicle  Program  Tow  Lot  Support'  subsection),  the  tow  elements  of  the  Vendor's  Boot 
and  Tow  System  shall  be  utilized  by  City  staff  to  accommodate  certain  abandoned 
vehicle  scenarios.  These  scenarios  relate  to  the  fact  that  once  at  the  Tow  Lot,  an 
abandoned  vehicle  may  be  placed  into  storage: 

1)  for  auction  if  the  vehicle  is  determined  to  possess  sufficient  value;  and/or 

2)  pending  retrieval  by  the  owner  within  a  short  time  period  following  the  tow. 

For  both  of  these  situations,  the  storage  fee  elements  of  the  Boot  and  Tow  System 
would  be  activated  and  storage  fees  would  accumulate  according  to  the  storage  fee 
formula  set  forth  in  the  'Boot  and  Tow  System'  section  of  this  RFP.  This  will  continue 
up  until  the  point  in  time  that  Tow  Lot  personnel  indicates  that  the  vehicle  has  been 
auctioned,  retrieved,  repossessed  or  disposed  of. 

For  scenario  #2  above,  or  due  to  some  other  circumstances,  Tow  Lot  personnel  would 
also  need  to  create  a  tow  record. 


Tow  fees  for  abandoned  vehicle  violations  shall  be  on-line,  real-time  data  entered  by 
Tow  Lot  staff.  The  Vendor  shall  accommodate  a  dollar  amount  'tow  fee'  as  determined 
by  the  City. 

The  creation  of  a  tow  record  typically  occurs  when  the  City  determines  that  a  vehicle 
should  not  be  processed  as  abandoned.  In  such  an  instance,  no  abandoned  vehicle 
record  would  be  created  by  the  City. 

However,  the  Vendor  shall  provide  the  flexibility  to  create  a  tow  record  for  a  vehicle 
that  is  processed  as  abandoned,  and  where  an  abandoned  vehicle  record  is  created  by  the 
City. 
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Tow  Fees  -  The  system  shall  automatically  process  the  creating,  transferring  and 
exporting  of  information  for  tow  record  to  the  Boot  &  Tow  subsystem  using  the 
information  already  supplied  in  the  AVR  System.  There  might  also  be  a  need  to 
return  such  records  from  AVR  status  back  to  an  active  AVR  status. 

Scanning  of  AVR  Documents  -The  system  shall  accommodate  the  scanning  of  AVR 
Tickets  and  supporting  documents  of  AVR  information  and  the  association  of  such 
scanned  documents  to  the  AVR  record.  The  Vendor  shall  provide  hardware  and  a 
communication  environment  capable  of  supporting  this  component. 

Creation  of  AVR  Complaints  -  The  system  shall  accommodate  the  ability  to  enter 
Abandoned  Vehicle  Complaints  in  a  similar  fashion  to  the  Mayors  24  Hour  Hotline. 
These  entries  shall  be  integrated  to  appear  in  the  PreList  function  in  a  like  and  similar 
way  that  the  24  Hour  Hotline  complaints  are  treated.  There  shall  be  a  reporting 
capability  on  such  records  similar  to  those  received  via  the  Mayors  24  Hour  Hotline. 

(4.13.11)  Qualifying  Statement  Regarding  Tow  Lot  Support 

The  City  wishes  to  qualify  the  requirement  that  the  Boot  and  Tow  System  support  the 
Abandoned  Vehicle  System. 

From  the  perspective  of  the  City,  it  appears  reasonable  to  utilize  portions  of  the  Boot 
and  Tow  System  for  abandoned  vehicle  support.  The  City's  objective  in  this  regard  is  to 
optimize  operational  efficiency  and  effectiveness  through  the  utilization  of  one  unified 
and  integrated  system. 

However,  a  prospective  Vendor's  Abandoned  Vehicle  System  may  support  the  above- 
mentioned  tow  and  storage  functions  within  their  Abandoned  Vehicle  System.  This 
arrangement  may  be  acceptable  so  long  as  the  operational  and  on-line  inquiry  functions 
that  must  be  performed  by  the  City  are  provided  for  in  a  user-friendly,  integrated, 
efficient  and  effective  manner. 

The  AVR  System  shall  be  fully  integrated  with  the  core  Parking  Violation  System  via 
an  operationally  efficient  and  effective  manner  in  such  a  way  as  to  optimally  interact 
with  all  applicable  subsystems  or  components  of  the  core  system  in  an  integrated 
manner. 

(4.13.12)  Abandoned  Vehicle  Custody  Notification 

The  Vendor  shall  provide  the  capability,  for  vehicle  impoundment  (i.e.,  vehicles  that 
have  been  towed  to  the  Tow  Lot  as  a  result  of  abandonment  and  are  to  be  held  for 
auction)  to  automatically  generate  a  Vehicle  Notification  Letter  to  the  registered  owner 
of  said  vehicle,  so  informing  them  that  the  city  is  in  possession  of  the  abandoned 
vehicle.  The  Vendor  shall  provide  the  capability  for  City  personnel  to  manually 
generate  such  Vehicle  Notification  Letters.  A  record  of  all  Vehicle  Notification  Letters 
shall  be  maintained  and  displayed  in  the  Vendor's  PVPMISS  and  available  to  all  City 
personnel  via  the  Boot  and  Tow  System  as  well  as  other  Customer  Service  PVPMISS 
screens  of  primary  interest  (i.e.,  Ticket  level  Data  Screen)  via  a  user  friendly  efficient 
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and  effective  manner.  Letters  manually  generated  shall  be  separately  noted  in  the 
Vendor's  system. 


(4.13.13)    Further  Requirements  for  Abandoned  Vehicle  Reporting  System 

As  stated  previously  in  this  section,  the  City  shall  utilize  the  Vendor's  Abandoned 
Vehicle  Reporting  System  to  accept  abandoned  vehicle  complaints  from  the  City's 
Mayor's  Office  in  an  automated  fashion  and  to  report  back  in  an  automated  fashion  to 
the  Mayor's  Office  the  subsequent  status  of  each  complaint. 

The  Vendor's  Abandoned  Vehicle  Reporting  System  shall  provide  the  maximum 
amount  of  user-friendly,  operationally  convenient,  efficient  and  effective  features  and 
functionality. 

The  Vendor's  Abandoned  Vehicle  Reporting  System  shall  be  completely  and 
comprehensively  integrated  with  all  systems,  subsystems  and  system  elements  of  the 
PVPMISS  that  are  set  forth  in  this  RFP. 
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ON-LINE  MULTIPLE  VEHICLE  -  SINGLE  OWNER/ENTITY  SYSTEM 

TMULTI  OWNER  SYSTEM) 
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(4.14)  ON-LINE  MULTIPLE  VEHICLE  -  SINGLE  OWNER/ENTITY 
SYSTEM  (MULTI  OWNER  SYSTEM) 


(4.14.0)  Definition  and  Objectives 

The  On-Line  Multiple  Vehicle  -  Single  Owner/Entity  System  (hereafter  referred  to  as  the 
Multi  Owner  System)  shall  be  provided  by  the  Vendor  to  reduce  certain  City  costs  and  to 
centralize  and  consolidate  the  customer  service  functions,  dunning  notice  activity,  and 
appeal  and  payment  processing  activities  for  entities  operating  multiple  vehicles  in  the  City 
of  Boston.  For  example,  to  assist  companies  that  operate  fleets  of  vehicles  to  make  timely 
payments  or  appeals  for  violations,  a  monthly  billing  report  shall  be  generated  for  a 
participating  company  rather  than  multiple  dunning  notices  being  mailed.  (This  also 
reduces  City  costs  for  postage,  forms,  etc.) 

The  City  shall  utilize  the  Multi  Owner  System  for  the  following  four  (4)  categories  of 
entities,  which  are  subject  to  increase,  and  which  are  described  in  this  section: 

-  Fleet  Vehicles 

-  Government  Vehicles 

-  Dealer  Plate  Vehicles 

-  Lease/Rental  Companies  submitting  surcharge  payments. 


(4.14.1)  Summary  of  Support  Functions 

By  way  of  summary,  the  Multi  Owner  System  shall  efficiently  and  effectively 
support/provide  the  following  functions  and  activities: 

-  integration  with  the  PVPMISS 

-  on-line  access  and  inquiry 

-  creation  of  multi  owner  record  (by  City  staff) 

-  changes  to  multi  owner  record 

-  termination  of  multi  owner  record 

-  post/add  (multiple)  license  plates  to  the  multi  owner  record  (by  City  staff) 

-  delete  license  plates  from  the  multi  owner  record 

-  change  license  plate  information 

-  record  lease  vehicle  surcharge  payments  (by  City  staff) 

-  generate  consolidated  and  detailed  billing  reports  where  applicable 

-  update  payment 

-  depending  upon  category  of  entity,  prevent  certain  system  generated  activities  from 
occurring,  such  as:  name  and  address  requests,  application  of  penalties,  seizure, 
non-renewal,  'regular'  noticing. 

The  system  requirements  to  support  these  functions  are  described  in  detail  below. 
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(4.14.2)  Multi  Owner  Number 


All  license  plates  that  belong  to  a  particular  entity  shall  be  assigned  a  multi  owner  number 
(or  some  other  efficient  and  effective  unifying  and  descriptive  element)  that  is  common  to 
all  of  those  plates  so  as  to  generate  consolidated  and  centralized  information  about  the 
multiple  plates.  This  number  shall  also  be  utilized  to  differentiate  between  the  categories  of 
multi  owner  plates  and  specific  requirements  therein.  For  example,  as  described  in  this 
section,  a  Fleet  multi  owner  vehicle  shall  NOT  be  subject  to  seizure  while  a  Dealer  vehicle 
would  be  subject  to  this  action.  Also,  City  staff  must  be  able  to  visually  differentiate 
between  categories  of  entities  via  the  multi  owner  number  (at  present,  for  example,  all  multi 
owner  numbers  that  begin  with  the  numbers  '01'  belong  to  Fleet  Vehicles). 

It  should  be  noted  that  the  same  multi  owner  number  could  be  assigned  to  license  plates  that 
are  owned/registered  by  different  persons  or  entities. 

The  Vendor  shall  allow  for  the  manual  or  automatic  application  of  sequential  multi  owner 
numbers  to  all  categories  of  entities.  City  staff  shall  typically  apply  multi  owner  numbers 
to  all  categories  of  entities  except  for  Dealer  entities,  which  shall  be  assigned  this  number 
via  the  Vendor. 

(4.14.3)  On-Line  and  Comprehensively  Integrated  System 

The  Multi  Owner  System  shall  be  on-line  and  shall  be  integrated  with  the  PVPMISS.  In 
terms  of  examples  of  the  level  of  integration  required: 

a)  The  Multi  Owner  System  shall  provide  summary  dollar  amount  outstanding 
information  for  each  license  plate  that  belongs  to  an  entity.  Ticket  level 
information  can  be  provided  through  the  Master  Violations  File. 

b)  Ticket  payments  shall  be  processed  by  the  City  through  the  On-Line,  Real-Time, 
'Point  of  Sale'  Payment  Processing  System  described  in  this  RFP.  The 
conveyance/'carry-over',  from  said  payment  processing  system  to  the  Multi  Owner 
System,  of  the  'Dollar  Amount  Paid'  for  violations  is  not  necessarily  required  so 
long  as  the  new  (post  payment)  'Outstanding  Dollar  Amount  Due'  is  updated  to 
reflect  (i.e.,  deduct)  the  amount  paid.  However,  'Dollar  Amount  Paid'  for 
lease/rental  vehicle  surcharges  shall  be  reflected  in  the  system  via  the  manual 
posting  of  said  surcharge  payment  to  the  Multi  Owner  System  by  the  City. 

c)  The  posting  of  a  license  plate  'Effective  Date'  (provided  by  the  entity)  shall,  in  the 
event  of  tickets  being  issued  prior  to  that  date,  result  in  the  'splitting'  of  that  plate 
record  to  ensure  that  the  multi  owner  entity  vehicle  is  not  booted  for  another 
lessee's  tickets,  etc. 

d)  Termination  of  a  license  plate  from  a  multi  owner  record  shall  result  in  all  tickets 
issued  subsequent  to  the  termination  date  to  be  processed  by  the  PVPMISS  in 
accordance  with  requirements  for  non-multi  owner  plates. 

e)  The  multi  owner  number  shall  be  displayed  on  general  inquiry  screens. 

f)  Additional  PVPMISS  interface  requirements,  for  example  non-application  of  late 
penalties,  are  set  forth  in  this  section. 

g)  The  Multi  Owner  System  shall  provide  the  capability  for  the  Vendor  to  reapply 
overpaid  ticket  amounts  to  outstanding  ticket  amounts,  in  accordance  with  City 
reapplication  criteria,  utilizing/matching  on  multi  owner  number. 
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(4.14.4)  On-Line  Data  Entry  and  Inquiry  /  Access  Screens 


The  City  shall  be  responsible  for  data  input  of  multi  owner  data  and  information.  The  on- 
line data  entry  and  data  inquiry  of  all  multi  owner  data  and  information  must  be  provided 
for  in  a  user-friendly  and  operationally  convenient,  efficient  and  effective  manner. 

Inquiry  screens  format  shall  accommodate  the  need  for  minimal  and  efficient  access  and 
scrolling  routines  through  the  user-friendly  consolidation  of  data  on  screens.  Two  primary 
access  screens  are  required: 

(1)  for  a  multi  owner  entity  record,  and 

(2)  for  the  license  plate  information  associated  with  the  entity. 

(Data  field  and  other  requirements  for  these  two  information  areas  are  described  on  the 
following  pages.) 

The  creation,  modification  and  termination  functions  required  for  both  the  owner  entity 
record  and  license  plate  information  can  be  provided  through  sub-screens,  provided  that 
access  to  sub-screens  is  direct  through  data  elements  of  primary  interest  from  either  of  the 
two  primary  screens. 

Initial  on-line  access  shall  be  conducted,  at  a  minimum,  via:  (a)  entity  name,  and  (b)  entity 
multi  owner  number.  This  access  shall  allow  users  to  access  either  the  owner  entity  screen 
or  the  plate  information  screen. 

Also,  users  shall  be  able  to  directly  scroll  between  the  owner  entity  screen  and  the  plate 
information  screen. 

Further,  regarding  the  license  plate  information  screen,  users  shall  be  able  to  directly  access 
a  particular  license  plate's  information  without  page  scrolling  via  the  data  input  (on  the 
license  plate  information  screen)  of  the  plate  in  question.  The  Vendor  shall  also  provide 
users  with  the  option  of  selecting  access  for  the  following  status  categories  of  license  plates: 

-  ALL  PLATES  (all  plates  regardless  of  whether  active,  terminated  or  dollar  amount 
outstanding  —  the  system  shall  initially/automatically  default  to  this  option) 

-  ACTIVE  PLATES  (all  plates  that  are  not  terminated  regardless  of  whether  a  dollar 
amount  outstanding  is  zero  or  greater  than  zero) 

-  OPEN  PLATES  (all  plates  with  a  dollar  amount  outstanding  greater  than  zero) 

-  TERMINATED  PLATES  (all  plates  that  have  been  terminated). 
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(4.14.5)  Multi  Owner  Entity  Record  and  Access  Screen: 
Creation.  Changes  to  and  Termination 

The  minimum  required  data  fields  for  a  Multi  Owner  Entity  Record  Screen  are  described 
below.  Unless  otherwise  noted,  the  data  that  shall  comprise  these  fields  shall  be  entered  by 
the  City: 

-  ABBREVIATED  NAME  of  the  entity  (minimum  of  15  characters) 

-  COMPLETE  NAME  of  the  entity  (minimum  of  35  characters) 

-  STREET  MAILING  ADDRESS  (minimum  of  60  characters  to  accommodate  all 
possibilities) 

-  CITY  MAILING  ADDRESS  of  the  entity 

-  STATE  MAILING  ADDRESS  of  the  entity  (2  characters) 

-  ZIP  CODE  (9  characters) 

-  MULTI  OWNER  NUMBER  (minimum  of  9  characters) 

-  CONTACT  PERSON 

-  TELEPHONE  NUMBER 

-  CLERK  ID  NUMBER  of  person  creating  record,  etc. 

-  DATE  CREATED  should  be  automatically  entered  by  the  system 

-  DATE  LAST  CHANGED  to  capture  the  date  of  last  revision  (should  be 
automatically  entered  by  the  system) 

-  TERMINATION  DATE  if  entity  withdraws  or  is  terminated  from  the  multi  owner 
program. 


Due  to  address  changes,  personnel  changes,  etc.,  the  above  information,  once  entered,  will 
need  to  be  efficiently  changed  by  the  City.  However,  the  Multi  Owner  Number  and  system 
generated  dates  shall  not  be  subject  to  change. 


Also,  the  Vendor  shall  provide  for  the  efficient  termination  of  an  entity  from  the  multi 
owner  system.  However,  the  data  and  information  entered  for  the  entity  shall  be  retained 
by  the  system  until  the  Vendor  is  notified  otherwise  by  the  City. 


194 


(4.14.6)  License  Plate  Information  Records  and  Access  Screen: 
Creation/Posting.  Changes  to  and  Termination 

The  License  Plate  Information  Records  and  Access  Screen  shall  contain  a  minimum  of  two 
main  components: 

1)  Entity  Summary  Information  (from  the  Multi  Owner  Entity  Record),  and 

2)  License  Plate  Detail  Information  (to  be  sorted  in  alpha/numeric  order  and  preferably 

for  a  minimum  of  ten  license  plates  per  screen). 

1)  Entity  Summary  Information:  The  minimum  required  data  fields  for  Entity  Summary 
Information  are  described  below: 

-  MULTI  OWNER  NUMBER 

-  ENTITY  NAME  AND  ADDRESS 

-  ENTITY  PHONE  NUMBER 

-  ENTITY  CONTACT  PERSON 

-  DATE  RECORD  CREATED 

-  DATE  TERMINATED 

2)  License  Plate  Information:  The  minimum  required  data  fields  for  License  Plate  Detail 
Information  are  described  below.  Unless  otherwise  noted,  the  data  that  shall  comprise 
these  fields  shall  be  entered  by  the  City: 

-  STATE,  PLATE  NUMBER  (plate  type  should  also  be  included  via  abbreviation  of 

type) 

-  EFFECTIVE  DATE  of  license  plate  (which  is  supplied  to  the  City  by  the  entity  and 
shall  define  the  point  in  time  that  tickets  issued  to  a  plate  are  to  be  treated  as  multi 
owner  tickets) 

-  ENTITY  VEHICLE  NUMBER  (an  entity  may  internally  assign  an  identification 
number  to  track  their  vehicles  —  a  minimum  of  9  characters  is  required) 

-  TOTAL  DOLLAR  AMOUNT  OUTSTANDING  (including  fines,  penalties  and  fees 
—  this  amount  shall  be  automatically  entered  by  the  system) 

-  TERMINATION  DATE  (the  date  that  a  vehicle  is  listed  as  no  longer  belonging  to 
an  entity  and  the  date,  after  which,  tickets  issued  to  a  vehicle  are  not  processed 
according  to  multi  owner  requirements). 

The  following  information,  once  entered,  may  need  to  be  efficiently  changed  by  the  City: 
Effective  date,  Entity  vehicle  number  and  Termination  date. 

Also,  the  Vendor  shall  provide  for  the  efficient  termination  of  a  license  plate.  However,  the 
data  and  information  entered  for  the  plate  (excluding  TOTAL  AMOUNT  DUE)  shall  be 
retained  by  the  system  until  the  Vendor  is  notified  otherwise  by  the  City. 
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(4.14.7)  Additional  Requirements  for  Dealer  Vehicles 


Proposers  should  refer  to  Vendor  responsibilities  for  Dealer  plates  set  forth  in  the  'Registry 
of  Motor  Vehicles  Interface  System  and  Requirements'  section  of  this  RFP,  specifically 
'Section  5  License  Plate  Registrant  Identification  Information'. 

Dealer  plate  information  that  shall  be  secured  by  the  Vendor  from  the  MA  RMV  (at  a 
minimum,  once  per  year),  in  addition  to  being  applied  to  the  Master  Violations  File,  shall 
be  assigned  to  the  Multi  Owner  System  so  that  all  license  plates  with  outstanding  tickets 
registered  to  a  particular  Dealer  entity  are  consolidated. 

Plates  assigned  to  Dealer  entities  shall  NOT  be  exempt  from  any  ticket  late  penalty  or 
enforcement  action  (e.g.,  booting)  described  in  this  RFP.  The  City's  objective  in  including 
these  plates  in  the  Multi  Owner  Program  is  primarily  related  to  consolidated  noticing  and 
efficient  customer  service.  Toward  this  end,  the  Vendor  shall  utilize  the  SPV  and  Seizure 
Notices  (described  in  the  'Noticing'  section  of  this  RFP)  for  dunning  notice  purposes. 


(4.14.8)  Additional  Requirements  for  Fleet  Vehicles  and 
Government  Vehicles 

To  participate  in  the  multi  owner  program,  interested  and  eligible  fleet  entities  (e.g,  utility 
and  courier  companies)  are  required  to  sign  an  agreement  letter  with  the  City  specifying 
their  intentions  to  pay  or  appeal  all  violations  when  billed  monthly.  Participating  entities 
will  then  supply  the  City  with,  among  other  things,  the  registration  numbers  of  all  vehicles 
in  their  fleet. 

The  Vendor  shall  provide  a  Multi  Owner  System  that  enables  the  City,  on  a  monthly  basis, 
to  send  participating  entities  a  consolidated,  hard-copy  report  or  a  computer  disk  for 
invoicing  purposes.  (The  Vendor  shall  update  payments  for  specified  Fleet  Companies  via 
a  batch  payment  update,  i.e.,  City  staff  shall  not  process  such  payments.)  The  report  must 
be  in  plate  number  order  and  contain,  at  a  minimum,  the  following  information: 

-  outstanding  violation  numbers 

-  issue  dates 

-  issue  times 

-  location  of  violation 

-  type  of  violation 

-  make  of  car 

-  amount  paid  (only  for  open  tickets,  if  applicable) 

-  penalty  amount  reduced  (i.e.,  not  applied) 

-  total  amount  due,  and 

-  a  notation  which  denotes  if  a  violation  has  a  hearing  scheduled. 
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A  report  shall  be  generated  on  an  as  need  bases,  for  plate  audit  purposes,  and  all  plates  that 
have  been  registered  with  the  Multi  Owner  System  for  a  particular  entity  must  appear  on 
the  report  regardless  if  any  violations  have  been  issued  to  them. 

Violations  issued  to  Fleet  and  Government  vehicle  registrations  residing  in  the  Multi  Owner 
System  shall  not  be  assessed  late  penalties.  In  addition,  standard  notices  such  as  the 
Overdue  Notice,  etc.,  shall  not  be  generated.  Further,  participating  registrations  shall  not  be 
deemed  boot  eligible,  shall  be  exempt  from  non-renewal  action,  and  name  and  address 
information  shall  not  be  requested  from  the  Registry  of  Motor  Vehicles. 

Entities  not  fulfilling  their  obligations  to  the  City  shall  be  removed  from  the  Fleet  Vehicle 
System.  Upon  such  action  by  the  City,  the  Vendor  shall  automatically  resume  all  collection 
activities  including  late  penalty  assessment,  name  and  address  request,  non-renewal  action, 
and  boot  eligibility  determination. 


(4.14.9)  Additional  Requirements  for  Lease/Rental  Surcharge  Payments 
and  Notice  to  Prospective  Vendors 

The  City  receives  a  60  cent  surcharge  fee  for  each  lease,  rental  or  taxi  contract  written  in 
the  City  of  Boston.  The  City  desires  to  utilize  the  Multi  Owner  System  to  manage  the 
surcharge  collection  responsibilities. 

Prospective  Vendors  shall  be  advised  that  the  requirements  for  this  surcharge  collections 
and  management  are  at  present  unique  to  this  particular  function  —  primarily  due  to  the 
absence  of  plate  or  violation  records  and  the  posting  of  entity-related  (versus  plate-related) 
payment  amounts.  However,  the  tasks  associated  with  surcharge  payments  do  include  the 
utilization  of:  (a)  the  Multi  Owner  Entity  Record  (e.g.,  entity  name,  address,  contact  person, 
etc.)  for  customer  service  and  other  purposes,  and  (b)  the  NAME  and  MULTI  OWNER 
NUMBER  for  access  purposes.  (Also,  in  the  event  that  the  City  were  to  implement  any 
type  of  entity  FEE,  which  is  not  anticipated  at  present,  collection  management  tasks  for 
lease/rental  surcharge  collections  would  not  be  unique  to  the  requirements  of  the  Multi 
Owner  System.) 

Therefore,  although  it  is  desired,  Prospective  Vendors  are  not  required  to  include  or  to 
integrate  the  below  listed  requirements  in  their  Multi  Owner  System.  However,  in  the  event 
that  surcharge  management  and  collections  are  not  integrated  into  the  Multi  Owner  System, 
all  before  mentioned  requirements  that  relate  to  the:  Multi  Owner  Entity  Record,  multi 
owner  number,  on-line  system,  user-friendly  and  operationally  convent  data  input  and 
access,  etc.,  shall  be  provided  by  the  Vendor  in  an  efficient  and  effective  manner. 
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In  terms  of  screen  requirements,  preferably  a  minimum  of  ten  surcharge  payments  shall  be 
recorded  per  screen.  Further,  the  City  requires  that  this  information  be  included  on  the 
Multi  Owner  Entity  Record  Screen  or  directly  accessed  from  this  screen.  The  additional 
minimum  required  data  fields  for  surcharge  collections  and  management  are  described 
below: 


-  Payment  due  date  -  shall  be  entered  by  the  City. 

-  Amount  paid  -  shall  be  entered  by  the  City. 

-  Date  paid  -  shall  be  entered  by  the  City. 


Each  week  the  Vendor  shall  provide  a  Surcharge  Deposit  Report  which  shall  include  the 
following  information: 


-  multi  owner  number 

-  payment  amount  by  company 

-  company  name 

-  street  address 

-  city  and  state  address 

-  payment  process  date 

-  total  payment  amount. 
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PARKING  METER  MANAGEMENT  SYSTEM 
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(4.15)  PARKING  METER  MANAGEMENT  SYSTEM 


(4.15.0)  On-Line  and  Integrated  System 

The  Vendor  shall  provide  an  on-line  integrated  Parking  Meter  Management  System 
which  shall  maintain  an  inventory  of  all  meters,  maintain  a  record  of  the  current  and  past 
meter  status,  and  record  the  type  and  frequency  of  repairs  for  each  meter. 

Users  of  these  features  shall  include  parking  meter  maintenance  and  repair  personnel 
located  at  the  BTD's  Southampton  Street  facility,  parking  ticket  customer  service 
personnel  located  at  City  Hall,  and  parking  enforcement  personnel  located  at  the  BTD's 
Frontage  Road  facility. 

In  addition  to  access/inquiry  screens  for  the  system  features  described  in  this  section,  the 
Meter  Management  System  must  accommodate  the  user-friendly  and  operationally 
convenient  and  effective  on-line  access  of  meter  outage  and  repair  data  (consolidated 
onto  a  single-screen)  via  the  General  Inquiry  Screens  (for  use  by  parking  ticket  personnel 
in  the  event  a  parking  violation  is  associated  with  a  parking  meter  number). 


(4.15.1)  Data  Input  /  Data  Entry 

The  Meter  Management  System  shall  provide  for  the  user-friendly  and  operationally 
convenient  and  effective  data  input/entry  of  parking  meter  data  by  authorized  City 
personnel.  The  City  of  Boston  utilizes  MacKay  electronic  parking  meters  (Guardian  XL) 
equipped  with  hand-held  devices  (Jett  XL)  which  collect  data  from  the  meters  via 
infrared  signal.  The  City  also  utilizes  Parkeon  Multi-space  parking  meters  (Strada  BNA 
model).  This  data  shall  then  be  uploaded  to  the  Vendors  Meter  Management  System. 
This  data  shall  include: 

a)  meter  revenue  data  (collection  route  number,  crew  number,  number  of  meters  on 
route,  the  number  of  days  in  the  month  that  meters  were  authorized  for 
collections,  and  amount  collected  by  route) 

b)  meter  outage  and  repair  data  (outage  type  according  to  outage  codes  provided  by 
BTD  [2  character,  alpha  codes],  crew  and  section  the  outage  was  reported  by,  the 
date  and  time  of  outage,  repair  type  according  to  repair  codes  provided  by  BTD, 
meter  number,  date  and  time  of  repair,  and  who  performed  the  repair) 

c)  and  meters  installed  or  taken  out  of  service  (meter  number  and  date). 
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(4.15.2)  System  Features 


The  Meter  Management  System  shall  include  at  a  minimum  the  following  features,  which 
shall  be  user-friendly  and  operationally  convenient,  efficient  and  effective: 

1)  Provide  a  primary  parking  meter  record  which  consists  of:  make,  model,  time 
limit,  days  and  hours  in  effect,  type  of  space,  meter  number,  neighborhood/district 
in  which  located,  street  name,  names  of  intersecting  streets  at  both  ends  of  the 
block,  side  of  the  street  where  located,  rate,  manufacturer,  model  number,  date  of 
purchase,  date  installed,  status  (in  or  out  of  operation  with  applicable  dates)  and 
preventive  maintenance  dates; 

2)  Allow  for  the  inquiry,  entry  and  update  of  information  about  any  individual  meter 
by  its  meter  number; 

3)  Allow  for  a  user  to  make  global  changes  to  the  records  of  all  meters  on  the  same 
side  of  the  same  block; 

4)  Display  upon  inquiry  the  collection  route,  maintenance  route,  number,  makes, 
time  limits  and  rates  of  meters  on  any  block  by  entering  its  location 
(neighborhood  /  district,  street  name,  side  of  street  and  either  block  or  intersecting 
streets); 

5)  Allow  for  the  inquiry,  entry  and  update  of  outage  and  repair  information  for  any 
meter  by  meter  number,  maintenance  route,  outage  applicable  to  multiple  meters, 
or  pending  repair  applicable  to  multiple  meters; 

6)  Allow  for  inquiry  on  all  pending  and  completed  repair  items,  by  meter  number; 

7)  Allow  for  inquiry  on  daily  and  total  to-date  yearly  summary  status  statistics  for  all 
meters  in  the  system,  to  include  the  number  of  meters  installed,  number  of  meter 
outages  repaired,  number  of  meters  placed  temporarily  out  of  service  and  returned 
to  service,  number  of  removed  meters,  number  of  replaced  meters,  and  number  of 
meters  that  went  out  of  service  and  returned  to  service  for  reasons  other  than 
temporarily  out  of  service  or  removal; 

8)  Simulate  the  effect  of  changes  in  meter  rate,  time  and  amount/number  of  meters  in 
order  to  project  revenue  impact. 
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(4.15.3)  Meter  Outage  /  Repair  Screen 

This  screen  must  provide  a  record  of  the  outage  and  repair  of  a  parking  meter. 
Outage  information  shall  include,  at  a  minimum: 

-  outage  date 

-  outage  reason 

-  ticket  number  associated  with  each  outage 

-  source  of  each  outage  report. 

Repair  data  shall  include,  at  a  minimum: 

-  the  date  and  time  of  repair 

-  repair  crew 

-  action  performed  as  a  result  of  each  outage  report. 

A  notation  must  indicate  additional  records  contained  on  additional  screens 
accommodated  by  a  scrolling  function. 

As  previously  stated,  the  Vendor  shall  accommodate  the  user-friendly  and  operationally 
convenient  and  effective  on-line  access  of  meter  outage  and  repair  data  directly  via  the 
General  Inquiry  Screens  (for  use  by  parking  ticket  personnel  in  the  event  a  parking 
violation  is  associated  with  a  parking  meter  number). 

Access  to  this  screen  shall  also  be  available  independent  of  any  parking  ticket  inquiry, 
e.g.,  separate  menu  item. 

Meter  outage  and  repair  data  shall  be  maintained  on  the  On-Line  System  until  the  Vendor 
is  instructed  to  remove  such  data  via  archive  procedures  approved  by  the  City. 
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(4.15.4)  Management  and  Activity  Reporting 


The  Vendor's  Meter  Management  System  shall  routinely  provide  paper  and/or 
electronic  copies  of  the  following  reports  relating  to  meter  management: 

1)    A  daily  meter  outage  report,  listing  all  reported  meter  outages  by 

maintenance  route.  This  report  shall  identify  meters  affected  by  outages  and 
meter  location,  type  of  outage,  date  and  time  reported,  and  crew 
identification,  and  shall  also  include  repair  action,  date,  time  and  person  who 
repaired  the  meter. 


2)    A  monthly  meter  collection  report,  listing  by  week  of  the  month,  the 

collection  route  and  crew,  and  the  number  of  meters  from  which  collections 
were  obtained.  Also,  the  number  of  days  in  which  meters  were  authorized  for 
collections,  the  projected  revenue  collection  for  that  period  based  on  the 
average  meter  revenue  per  day  for  that  month  in  the  previous  year  for  that 
collection  route,  the  actual  amount  collected,  the  date  of  revenue  deposit,  and 
totals. 


3)    A  daily  meter  repair  report,  listing  all  repairs  to  meters  by  maintenance  route 
and  meter  number.  This  report  shall  list  the  type  of  outage,  type  of  repair, 
and  repair  date  and  time. 


4)    A  weekly  meter  repair  activity  report,  listing  repairs  by  type  and  maintenance 
route.  This  report  shall  list  the  number  of  repairs  within  each  maintenance 
route,  by  repair  type  and  the  percentage  of  total  repairs  by  each  repair  type, 
and  cumulative  monthly  and  year  to  date  repair  totals. 


5)    A  weekly  meter  inventory  report,  indicating  the  operative  status  of  meters  by 
collection  route.  This  report  shall  list  the  number  of  in-service  meters, 
bagged  meters,  not-in-service  meters,  removed  meters  and  total  meters,  with 
totals. 


6)    A  monthly  meter  revenue  report,  listing  meter  collections  by  collection  route. 
This  report  shall  list  the  number  of  meters  and  number  of  collections  in  each 
route,  dollar  amount  of  collections  for  the  same  month  in  the  previous  year, 
the  dollar  amount  of  collections  in  the  reporting  month,  the  percentage 
change  from  year  to  year,  the  average  revenue  per  meter  for  the  reporting 
month,  and  year  to  date  dollar  amount  of  collections. 
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A  monthly  meter  revenue  report  comparing  collections  to  projections.  This 
report  shall  include,  by  collection  route,  the  projected  collections  amount 
based  on  the  same  time  period  in  the  previous  year,  the  amount  collected,  and 
percentage  of  difference  between  projected  and  collected. 


A  monthly  meter  maintenance  activity  report,  by  maintenance  route, 
summarizing  meter  data.  This  report  shall  list  the  operative  time  period  for 
meters  in  each  route,  the  monetary  rate  per  hour  or  minutes,  manufacturers  of 
meters,  and  number  of  meters  installed  by  each  manufacturer. 


A  monthly  meter  inventory  report,  listing  all  meters  by  street,  block  and 
collection  route.  This  report  shall  also  include  meter  numbers,  side  of  the 
street,  manufacturer,  days  and  hours  operable,  time  limits,  dates  of 
installation,  and  service  status  (in  service  or  out  of  service). 


A  monthly  meter  inventory,  listing  the  number  of  meters,  time  limit,  hourly 
rate  and  manufacturer(s)  of  meters  in  each  maintenance  route. 
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4.16 

SIGN  MANAGEMENT  SYSTEM 
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(4.16)  SIGN  MANAGEMENT  SYSTEM 


(4.16.0)  On-Line  and  Comprehensive  Sign  Management  Work  Order  System 

The  Vendor  shall  provide  a  comprehensive,  on-line  Sign  Management  System  for  the 
maintenance,  update,  and  access  of  sign  data  for  which  a  'work  order'  has  been 
generated  by  City  staff. 

Presently,  all  sign  activities  and  operations  conducted  by  the  City  are  scheduled  and 
executed  by  BTD  staff  via  a  written  work  order.  Work  orders  serve  as  instructions  to 
install,  remove,  replace,  or  modify  signage,  due  to  a  missing  or  damaged  sign,  a  new 
regulation,  etc. 


(4.16.1)  Maintenance  of  All  Sign  Activity 

Sign  data  shall  be  maintained  for  all  signs  maintained  by  the  Boston  Transportation 
Department,  including  parking  regulation  signs,  street  name  signs,  traffic  regulation 
signs  (such  as  'Stop'  signs,  etc.),  and  miscellaneous  informational  signs.  There  are 
currently  approximately  54,000  work  order  records  on  the  system,  and  approximately 
7,000  -  8,000  work  orders  are  entered  to  the  system  per  year.  However,  this  number 
may  increase  for  unforeseeable  reasons  and  the  Vendor  must  have  the  capability  to 
accommodate  up  to  20,000  work  orders  per  year. 


(4.16.2)  Creation  of  Records 

City  staff  shall  input  the  data  from  scheduled  and/or  completed  work  orders  so  as  to 
create  comprehensive  records  of  on-street  signage.  Said  records  shall  include,  at  a 
minimum,  the  following  data  and  information  for  each  work  order: 

-  work  order  number 

-  status  ("complete"  or  "active") 

-  street  name  and,  when  available,  street  number 

-  neighborhood 

-  date  work  order  created 

-  investigator  name 

-  reason  for  work  order  (e.g.,  new  regulation,  repair) 

-  date  of  data  entry 

-  user  i.d.  of  data  entry  operator 

-  date  and  time  actual  work  completed 

-  work  crew  i.d. 

-  exact  location  of  sign  activity  (up  to  10  per  work  order) 

-  type  of  activity  (installation,  removal,  etc.  —  up  to  10  per  work  order) 

-  type  of  sign  (up  to  10  per  work  order) 

-  description  of  sign  verbiage  (up  to  10  per  work  order). 

Data  input  of  work  order  information  shall  be  operationally  convenient,  efficient  and 
effective. 

Such  work  order  records  shall  permanently  reside  in  the  System  unless  the  Vendor  is 
otherwise  notified  by  the  City. 
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(4.16.3)  On-Line  Access 


The  Sign  Management  System  shall  accommodate  user-friendly  and  operationally 
efficient  and  effective  on-line  access  for,  at  a  minimum: 

-  a  particular  work  order 

-  groups  of  work  orders. 

On-line  access  to  a  particular  work  order  record  shall  be  available  by  entering  the  work 
order  number. 

On-line  access  for  groups  of  work  orders  shall  be  available  through,  at  a  minimum,  each 
of  the  following  variables  or  combination  of  variables: 

-  crew  identification 

-  street  address 

-  neighborhood  and  work  order  status  (status  as  either  'complete'  or  'active') 

-  creation  date  and  work  order  status 

-  completion  date  and  work  order  status. 

Access  by  street  address  shall  produce  a  listing  of  work  orders  sorted  by  their  address 
on  the  street  and  shall  conveniently  scroll  to  work  orders  with  higher  and  lower 
addresses  on  the  same  street. 

Access  by  creation  or  completion  date  shall  produce  a  listing  of  work  orders  with  the 
entered  date  and  shall  conveniently  scroll  to  work  orders  with  earlier  and  later  dates. 

Access  by  other  variables  shall  sort  by  work  order  numbers. 

The  Sign  Management  System  shall  also  accommodate  on-line  access  to  parking 
regulation  work  orders  only  and  to  other  BTD  signs  only. 

All  of  the  above-mentioned  access  paths  shall  also  be  available  while  limiting  the 
response  to  'parking-regulation'  or  'non-parking'  signs  only. 

Each  work  order  record  shall  display,  on  a  single  screen  and  in  an  operationally 
convenient  manner,  each  data  field  listed  under  "Creation  of  Records",  above. 
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(4.16.4)  Edits  and  Controls 


The  system  must  also  include  a  table,  or  similarly  efficient  and  effective  item,  of  valid 
sign  codes  and  neighborhood  abbreviations.  (At  present,  there  are  11  neighborhood 
codes  and  approximately  170  sign  codes.)  The  table  shall  serve  as  a  quality  control 
edit,  to  prevent  data  entry  of  invalid  sign  and  neighborhood  codes,  and  must  be 
conveniently  accessed  and  modified  by  authorized  City  staff. 

Edits  shall  also  be  in  place  to  ensure  that  only  valid  dates  can  be  entered,  and  that  each 
work  order  number  is  unique  and  cannot  be  duplicated. 


(4.16.5)  Management  &  Operational  Reports 

The  Vendor  shall  provide  a  Management  &  Operational  Reporting  Package  containing 
information  on  the  Sign  Management  System.  Such  reporting  package  must  include, 
but  not  be  limited  to,  the  following  monthly  reports: 

a)  Sign  Management  Activity  by  Sign  Size  Report  —  For  each  of  24  sign  sizes 

(e.g.,  pentagon  22"  x  22"),  list  the  number  of  signs  installed,  replaced,  and 
removed,  as  well  as  the  total  number  erected  (installed  plus  replaced)  and  the 
total  sign  activity.  Within  each  size,  the  same  figures  shall  be  provided  for 
each  sign  code  (e.g.,  "rectangle  12  x  18"  may  be  broken  down  to  PB11, 
PB15,  etc.) .  The  report  shall  conclude  with  a  total  number  of  signs,  total 
number  of  posts,  and  a  total  activity  figure  (incorporating  signs  and  posts). 

b)  Sign  Management  Activity  by  Sign  Report  —  For  each  of  approximately  170 

different  specific  sign  codes,  provide  the  number  of  signs  installed,  removed, 
and  replaced,  as  well  as  "total  activity"  for  that  sign  code.  Within  the  specific 
sign  code,  figures  shall  be  provided  for  each  of  11  neighborhoods.  The  report 
shall  conclude  with  a  total  number  of  signs  installed,  total  number  replaced, 
and  total  number  removed,  as  well  as  a  "total  activity"  figure  (incorporating 
installations,  replacements,  and  removals  of  all  signs). 

c)  Sign  Management  Installation  Report  —  For  each  of  11  neighborhoods,  provide 

a  listing  of  all  work  orders  completed;  include  for  each  work  order  the  work 
order  number,  the  date  written,  the  date  completed,  the  reason  for  the  work 
order  (e.g.,  installation),  the  street  name,  the  investigator's  initials,  and  the 
crew  identification.  The  report  shall  conclude  with  the  total  number  of  work 
orders  completed  citywide. 

The  City  may  require  that  these  reports  be  produced  on  a  quarterly  and/or  annual  basis 
as  well. 

The  Vendor  shall  also  produce  reports  of  damaged  and  missing  parking  regulation  signs 
(i.e.,  work  orders  that  have  not  been  completed)  on  an  "as  requested"  basis. 

The  City  may  require  the  provision  of  additional  management  reports. 
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(4.16.6)  Future  Interface  with  Core  PVPMISS 


At  this  time,  Sign  Management  is  not  required  to  interface  with  the  core  PVPMISS. 
However,  the  City  anticipates  that  during  the  course  of  the  contract  the  system  may  be 
required  to  accommodate  the  interface  of  parking  violation  sign  complaints  (received  by 
the  OPC)  with  the  operational  inventory  concerns  of  sign  maintenance  and  repair 
personnel.  The  main  feature  of  this  interface  function  would  likely  be  automated  and 
direct  access  to  signage  repair  records  from  the  parking  violation  computer  record, 
similar  to  that  of  Meter  Management. 


(4.16.7)  Future  Interface  with  Geographic  Information  System  (GIS) 

The  City  is  currently  reviewing  Geographic  Information  Systems  (GIS)  with  mapping 
components  to  display  all  "on-street"  parking  regulation  signs  (as  well  as  other  data).  If 
a  GIS  is  implemented,  the  Sign  Management  components  described  above  will  be 
required  to  interface  with  the  GIS.  Such  interface  should  ensure  that  sign  activity  data 
from  the  Sign  Management  System  will  be  updated  to,  and  reflected  on,  the  GIS 
display. 
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4.17 

INTERACTIVE  VOICE  RESPONSE  SYSTEM  (IVRS) 
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(4.17.0)  Overview  of  Vendor's  Responsibilities  for  IVRS 


The  Vendor,  at  its  cost,  will  be  required  to  install,  operate,  manage  and  provide  all  the 
software,  hardware,  programming,  maintenance,  technical  assistance  and  on-going  support 
services  for  the  IVRS.  The  City  requires  a  complete,  high  quality  new,  redundant  IVRS  at 
the  start  of  the  new  contract.  The  City  will  be  only  responsible  for  locating  the  hardware 
within  the  BTD/OPC  City  Hall  office  and  the  provision  of  the  telephone  lines  used  by 
customers  to  access  the  IVRS.  The  City  may  at  its  discretion  select  one  of  its  employees  to 
record  the  messages  to  be  played  on  the  IVRS.  The  Vendor  must  provide  on-site  support 
via  fully  trained  local  staff.  The  vendor,  at  its  cost,  will  maintain  on-site  service  agreement 
for  the  hardware  and  software  for  the  IVRS. 

The  Vendor  will  have  complete  responsibility  for  converting  all  the  current  IVRS 
applications  to  the  new  IVRS.  The  Vendor  is  required  to  design,  reconfigure,  develop, 
install,  test,  debug,  and  fine  tune  application  software,  scripts,  and  voice  files  from  current 
operations  onto  the  new  machines.  The  City  requires  that  the  scripts,  menu  options  and 
message  flows  be  identical  to  ones  currently  in  use.  Vendors  may  suggest  alternatives  that 
would  enhance  the  current  applications,  but  the  City  will  have  sole  discretion  to  accept  or 
reject  suggestions.  The  current  script,  flow,  and  menus  are  provided  as  an  appendix  to  this 
RFP.  (The  current  scripts,  menu  options  and  message  flows  have  proven  very  successful 
and  have  been  fined  tuned  and  thoroughly  debugged.)  In  addition,  the  City  will  require  the 
Vendor  to  significantly  expand  the  IVRS  for  other  applications  on  an  on-going  basis 
throughout  the  term  of  the  contract.  The  Vendor  will  be  required  to  perform  the  same 
services  on  new  applications,  as  it  is  required  to  perform  on  the  converted  applications. 
The  City  may  require  that  the  vendor  hire  a  professional  voiceover  company  or  individual 
to  re-record  the  entire  message  inventory.  The  Vendor  must  fully  integrate  the  IVRS  with 
thePVPMISS. 

The  Vendor  must  ensure  that  the  IVRS  product,  its  equipment  and  software,  be  equivalent 
or  exceed  the  current  state-of-the-art  IVRS  product  and  that  it  will  allow  for  growth  and 
change.  The  enhancements  and  growth  of  systems  and  services  will  be  provided  at  the 
complete  cost  of  the  Vendor.  The  equipment  provided  by  the  Vendor  must  be  proven  to  be 
fully  equivalent  or  exceed  product  specification  and  capabilities  reflected  in  section  4.17.3. 
The  current  equipment  was  purchased  in  2008.  The  ownership  of  the  new  IVRS  equipment 
will  be  turned-over  to  the  City  at  the  conclusion  of  the  PVPMISS  contract  issued  pursuant 
to  this  RFP.  The  new  IVRS  must  be  fully  compatible  with  the  new  ACD  as  talked  about  in 
section  4.17.5  and/or  the  existing  Definity  G3si  Automatic  Call  Distributor  if  the 
installations  are  not  on  the  same  day.  Further,  the  new  IVRS  should  be  user-friendly. 

The  Vendor  is  required  to  provide  the  City  with  usage  rights  and  a  copy  of  all  IVRS  scripts, 
flow  charts,  and  the  application  software. 

The  City  will  require  at  the  Vendor's  cost  that  the  following  be  provided  with  the  IVRS  at  the 
start  of  the  contract: 

•    Voice/Speech  recognition  and  interaction  -  It  will  be  required  that  the  vendor  provide  the 
same  interaction  with  voice  as  the  existing  system  does  with  the  touch-tone  phone.  The 
caller  must  have  the  choice  of  either  interacting  with  voice  or  the  touch-tone  phone. 

•    New  script/interaction  with  database  such  as  status  of  Resident  Parking  Permit  renewal 
applications  -  A  caller  will  be  able  to  find  the  status  of  their  application.  Ex: 
"Approved  and  should  be  receiving  the  permit  shortly",  etc. . . 
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The  Vendor  will  also  be  required  to  satisfy  many  IVRS  requirements  including,  but  not  limited 
to,  the  following  requirements. 

a)  Must  be  licensed  by  IVRS  manufacturer  to  maintain  system  and  work  with 

software,  and/or  identify  and  substantiate  how  the  equivalent  or  superior  level, 
quality  and  types  of  services  as  required  by  the  City  in  this  RFP  will  be  provided; 

b)  Must  be  proficient  in  the  software  utilized  in  the  development  of  the  applications; 

c)  Must  be  proficient  with  applicable  programming  logic; 

d)  Must  be  proficient  with  IVRS  environment  similar  and  comparable  to  Boston's 
PVPMISS; 

e)  Must  be  proficient  with  applicable  telecommunications  environment  including  IVRS 
interface/integration  (i.e.;  must  have  knowledge  of  a  Centrex  station  relation 
architecture  such  as  hookflash  transfer); 

f)  Must  be  able  to  proficiently  interface  with  the  PVPMISS  database; 

g)  Must  be  able  to  proficiently  interface  with  the  ACD  utilized  by  the  City; 

h)  Must  have  proficiency  with  developing  and  producing  a  wide  variety  of  IVRS 
operational  activity,  system  and  management  reports  on  a  daily,  weekly  and  monthly 
basis. 

i)  The  vendor  must  be  proficient  in  voice  recognition  technology. 
(4.17.1)  Overview  of  IVRS  Applications 

The  Interactive  Voice  Response  System  (IVRS)  is  an  interactive  informational 
distribution  system  which  automates  communication  between  a  telephone  caller,  the 
IVRS  and  the  (Vendor's)  PVPMISS  host  computer,  enabling  the  gathering  and  delivery 
of  information  on  a  24  hour,  7  day  a  week  basis  with  no,  or  limited,  human  operator 
assistance.  Approximately  350,000  calls  are  currently  processed  per  year  on  the  VRS. 

Callers  access  the  IVRS  by  dialing  different  BTD  information  telephone  numbers  (i.e., 
ticket  information,  resident  parking  information,  Tow  Lot  information,  abandoned 
vehicle  information,  central  administration  information,  and  pay-by-phone  information). 
Calls  are  initially  received  via  an  Automatic  Call  Distributor  (ACD)  and  forwarded  to 
the  IVRS.  The  callers  are  asked  to  select  (by  using  the  touch-tone  numbers  on  their 
telephones)  from  information  categories  that  will  provide  them  with  responses  to  their 
inquiries  or  disputes.  Callers  with  rotary  phones  are  automatically  transferred  to  an 
operator.  During  work  hours,  callers  can  request  at  their  discretion,  via  the  touch  tone 
keys  on  their  phone  and  voice,  direct  assistance  from  operators. 

The  IVRS  as  developed  by  BTD/OPC  is  a  customer-friendly,  cost-effective  solution 
that  helps  to  overcome  capacity  limitations  in  responding  to  inquiries  and 
implementing/maintaining  various  activities.  The  benefits  of  the  IVRS  are  numerous 
and  include  expanded  service  to  the  public  via  access  to  the  IVRS  24  hours  a  day,  7 
days  a  week;  increased  capacity  to  handle  phone  inquiries  thus  resulting  in  more  calls 
being  answered;  increased  staff  productivity  and  reduced  stress  levels  and  burnout; 
improved  image;  and  a  sustained/increased  revenue  stream. 
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(4.17.2)  IVRS  Applications 


The  City  has  implemented  the  IVRS  applications  in  phases,  commencing  in  November 
1989.  At  present,  the  IVRS  contains  four  separate  and  unique  applications  described 
below. 


(4.17.2.0)  Ticket  Information  Application 

This  was  the  first  application  to  be  implemented  on  the  IVRS  and  currently  occupies  twelve 
ports  in  the  IVRS,  one  of  which  is  designated  as  a  Watts  line  for  MA  residents  living 
outside  the  (Boston)  617  area  code.  The  ticket  information  lines  currently  provide 
information  to  approximately  800  callers  a  day.  This  application  provides  information  on 
how  to  dispute  a  ticket,  acceptable  payment  methods,  boot  information,  and  relevant  license 
and  registration  renewal  information.  It  also  allows  a  caller  to  access  the  PVPMISS  host 
computer  by  entering  a  ticket  number  or  Massachusetts  driver's  license  number  and 
provides  the  total  amount  due  for  a  ticket  or  all  registrations  associated  with  the  driver's 
license  number. 


(4.17.2.1)  Resident  Permit.  Central  Administration.  Abandoned  Vehicle  Application 

This  application  currently  occupies  four  ports  in  the  IVRS  and  provides  approximately  80 
to  100  callers  a  day  with  resident  parking  permit  information.  Callers  can  obtain 
information  concerning:  how  to  obtain  a  permit,  what  to  do  if  a  new  or  second  car  is 
purchased,  how  to  obtain  a  temporary  permit,  what  to  do  if  a  vehicle  is  leased  or  rented, 
visitor  parking  information,  etc.  The  Resident  Permit  application  will  access  the  PVPMISS 
host  computer  by  driver's  license  number  for  the  total  amount  of  parking  violations  due  on 
all  registrations.  Also,  information  on  abandoned  vehicle  notices  and  hearings,  and  access 
to  staff  members  of  the  Central  Administration  Unit,  can  be  obtained.  Future  integration 
with  the  Resident  Permit  component  of  the  PVPMISS  is  envisioned  where  by  the  caller 
could  obtain  permit  account  status  information. 


(4.17.2.2)  Tow  Lot  Application 

The  Tow  Lot  application  occupies  six  ports  in  the  IVRS  and  currently  provides 
approximately  150  to  200  callers  a  day  with  information  on  parking  violation  tows,  booted 
and  towed  vehicles,  directions  to  the  Tow  Lot,  information  on  abandoned  or  stolen  vehicles, 
and  vehicles  auctions.  This  application  also  allows  the  caller  to  access  the  PVPMISS  host 
computer  by  MA  driver's  license  number  for  the  total  amount  due  on  outstanding  tickets  for 
all  registrations.  The  Tow  Lot  is  located  off-site,  but  the  caller  dials  the  main  number  into 
the  IVRS  located  at  Boston  City  Hall.  If  they  choose  to  speak  with  an  operator,  the  call  will 
then  be  transferred  to  the  Tow  Lot. 
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(4.17.2.3)  Pay  by  Phone  Application 


The  Vendor  will  be  required  to  provide  the  Parking  Clerk  with  a  completely  developed  Pay 
By  Phone  operation  including  application  software,  support  and  maintenance;  financial 
transactions  and  relationships  with  banks,  the  City,  the  credit  card  companies  and  other 
involved  parties  including  clearinghouses  that  provide  real-time  authorizations;  and 
operational,  audit,  reporting,  reconciliation  functions  related  to  this  activity  also  at  its  cost. 
All  Pay-By-Phone  transactions  and  transfer  of  funds  to  City  designated  bank  accounts  must 
be  confirmed  within  24  hours.  The  Vendor's  staff  must  reconcile  all  pay-by-phone 
transactions  and  transferred  amounts  and  resolve  any  discrepancies. 

The  Vendor  will  be  responsible  for  paying  all  credit  cards  charges  and  fees  associated  with 
this  Pay-by-Phone  application.  The  Vendor  may  be  required  to  be  classified  as  the 
merchant  for  this  application.  In  the  event  of  a  chargeback/reversed  transaction,  the  City 
will  only  be  debited  by  the  amount  of  the  actual  payment  amounts  applied  to  tickets  or 
other  City  payment  items.  All  other  fees  charged  to  the  credit  card  holder  in  the  case  of  a 
chargeback/reversed  transaction  are  debited  to  the  Vendor. 

This  Pay  By  Phone  application  will  reside  on  the  IVRS,  will  occupy  a  minimum  of  eight 
ports  (with  the  capability  to  expand)  and  will  allow  callers  to  make  payment  for  outstanding 
tickets  via  Master  Card  and  Visa  (with  the  ability  to  add  Discover  and  American  Express) 
by  a  touch-tone  telephone  on  a  24  hour,  7  day  a  week  basis.  Payments  are  processed 
against  the  PVPMISS  on  an  on-line,  real-time  basis.  Pay  by  phone  enables  callers  to  pay  a 
single  ticket  by  entering  the  ticket  number,  to  pay  tickets  appearing  on  a  notice  by  entering 
the  notice  number,  or  to  pay  the  total  amount  due  on  a  registration  with  either  the  ticket 
number  or  notice  number.  At  present,  this  application  notifies  callers  if  their  vehicle  is  in  a 
boot  and  tow  status  and/or  if  their  license  or  registration  is  'non-renewed'  at  the  Registry  of 
Motor  Vehicles  (which  prevents  any  pay-by-phone  payment  transactions).  The  Vendor  will 
be  required  to  develop  applications  to  link  plates  assigned  to  the  same  registrant  to  allow 
pay-by-phone  for  registrants  in  non-renewal  status  or  with  booted  vehicles. 


(4.17.3)  IVRS  Hardware.  Software.  Features.  Capabilities  and  Reports 

The  actual  IVRS  hardware  is  located  in  BTD/OPC.  The  IVRS  product  is  from  InterVoice. 
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(4.17.3.0)  Current  System  Configuration 


The  current  system  configuration  utilizes  two  (2)  redundant  VRS  units,  connected  in 
parallel  to  a  series  of  Centrex  lines.  Additional  information  about  the  system  follows: 

2  -  HP  Proliant  DL380  G5 

2  -  Modems  (remote  monitoring) 

2  -3270  controller  cards 

2-17  GB  disk  space 

-  Remote  management  software 

2  -  C31  Interface  Boards 

2  -  VCD  80MHZ  Digital  Voice  Cards 


(4.17.3.1)  Equipment  Specifications 

Equipment  specifications  are  as  follows: 

Digitized  voice  rate 
Speech  Characteristics 
Vocabulary  Size 
Input 

Peripheral  Devices 
Programming 
Voice  Transfer 


Multifunctionality 


Remote  Access 


Connecting  Arrangement 


32K  bits/sec 

Word  and  Phrase  recording 
Unlimited  depending  on  disk  space 
DTMF 

External  modem,  phone  towers  chassis,  high 

speed  modem 

On-site  and  Remote, 

including  recording  voice 

Studio  quality, 

continuously  variable 

slope  delta  modulation 

(CVSD) 

Host  connection, 

hookflash  referral, 

digital  switching  among 

any  ports  connected  by 

the  system 

ISPY  with  Password 

protection  and 

call  back  protection  for 

diagnostics  and 

programming 

Phone  lines:  RJ11,  host 

interface:  supplied 

cable,  power:  115  VAC, 

Amp  dedicated  outlet 
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(4.17.3.2)  Software 


Programming  requires  a  license  from  Intervoice.  The  IVRS  contains  customized  software, 
utilized  to  address  specific  applications.  The  IVRS  environment  is  automated  and  is 
complicated  in  nature.  The  system  is  provided  with  multi-tasking  (which  allows  many 
programs  to  run  at  the  same  time  under  Windows  NT).  This  system  is  also  designed  to 
interface  with  the  Vendor-provided  PVPMISS,  phone  line  functions  and  a  run-time  interpreter, 
which  allows  the  programmer  to  program  an  application  to  handle  all  functions  required  within 
the  IVRS. 


(4.17.3.3)  Major  Features  and  Capabilities 

-  Accepts  voice  or  touch  input  from  touch-tone  phones 

-  Directs  callers  through  any  series  of  menu  selections 

-  Routes  callers  to  any  destination  telephone,  either 
internal  or  off-premise 

-  Communicates  with  more  than  one  host  computer 
simultaneously 

-  Quotes  amount  due  for  single  tickets,  notices  as  well  as 
license  plate  amounts  associated  with  registrant's 
driver's  license  (i.e.,  ticket  level  and  summary  level),  status 
on  tickets  and  Resident  Permits 

-  Registers  and  maintains  the  status  of  data 

-  Retrieves  PVPMISS  related  information  and  reports  it  to 
callers 

-  Switches  callers  to  human  operators  for  'live' 
assistance 

-  Monitors  and  controls  call  progress  status 

-  Communicates  with  any  variety  of  host  computers 

-  Produces  a  wide  variety  of  Management  Information 
Activity  Reports 
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(4.17.3.4)  VRS  Activity  Reports 

A  variety  of  informational  activity  reports  must  be  produced,  via  a  user  friendly  desktop 
application,  on  a  daily/weekly/monthly  basis  that  provide  at  the  minimum  the  following  types 
of  information: 

-  Total  calls  for  each  line  and  the  overall  total 

-  Total  calls  by  time  of  day 

-  Call  duration  counts 

-  Call  terminations  that  are: 

-  normal  terminations 

-  hang-ups 

-  calls  transferred 

-  prompt  timeouts 

-  menu  timeouts 

-  Menu  selections  with  counts 

-  Pay-by-Phone  on-line  payment  processing  reports. 

-  Pay-by-Phone  call  tracking  reports 


(4.17.4)  NEW  IVRS  Equipment  Required  to  be  Provided  by  the  Vendor 

At  a  minimum,  the  new  IVRS  must  be  comprised  of  the  equivalent  of  two  (2)  twenty-four  (24) 
port  entities.  Each  machine  will  be  equipped  with  the  ability  to  interface  with  at  least  twenty- 
four  (24)  analog  lines  and  be  expanded  to  the  full  capacity  at  some  future  date. 


(4.17.4.0)  Specifications  and  Requirements  for  the  New  IVRS  (must  be  equivalent  or 
exceed) 

1)  The  IVRS  will  be  comprised  of  two  (2)  twenty  four  (24)  port  entities.  Each  machine 
will  be  equipped  with  the  ability  to  interface  with  at  least  twenty-four  (24)  analog  lines  and 
be  expanded  to  the  full  capacity  at  some  future  date. 

a)  Each  machine  will  be  equipped  with  a  hard  disk  drive  of  at  least  2GB  in  storage 
capacity  and  have  the  capacity  to  add  and/or  upgrade  to  larger  storage  units  at 
some  future  time. 

b)  Each  machine  will  be  equipped  with  2GB  of  Ram,  minimum,  and  be 
expandable. 

c)  Each  machine  will  be  equipped  with  a  CPU  equivalent  to  an  Intel  Pentium 
2.8GHz,  or  faster.  The  machine  must  be  designed  so  as  to  be  upgradeable  to  a 
faster  CPU  at  some  future  date. 

d)  Each  machine  will  be  equipped  with  one  (1)  1.44  MB  3.5"  diskette  drive. 
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e)  Each  machine  will  be  equipped  with  a  56KB  modem  and  requisite  cable  (may 
be  internal  or  external).  Modem  must  be  equipped  either  via  hardware  and/or 
software  to  detect  and  automatically  step-down  transmission  speeds. 

f)  Each  machine  will  be  equipped  with  a  17"  LED  color  monitor,  pointing  device 
(mouse  preferred)  and  standard,  104+  keyboard. 

g)  Each  machine  will  contain  a  data  backup  unit  (i.e.  streaming  tape  drive  or 
equivalent). 

h)  Each  machine  will  operate  in  an  accepted,  generally  available  software 
operating  system  (e.g.  Windows  NT,  Unix). 

i)  Each  machine  will  be  equipped  with  a  3270  Bisync  SNA/SDLC  cluster 
controller  equipped  with  a  slave  processor  board  with  dual  port  high  speed 
memory  or  equivalent.  The  controller  board  can  be  configured  Bisync  and 
SNA  modes.  Connection  will  be  via  RS-232  to  modem  or  equivalent. 

j)  Each  machine  will  be  equipped  with  the  following  software  or  equivalent: 
Intervoice  V2  for  NT;  Connectlink/Async.  LeaveWord  and  YourVoice. 

k)  Each  system  will  be  equipped  with  the  ability  to  automatically  restart  when 
power  is  restored,  after  interruption  of  software,  hardware  and/or  power. 
Automatic  restart  capability  must  allow  monitoring  of  all  system  conditions 
(e.g.  power,  software,  system  errors)  such  that  failures  above  threshold  values 
will  allow  for  an  automatic  gracious  system  shutdown,  wait  for  a  pre-defined 
time,  restart  and  reboot  where  possible. 

NOTE:   These  requirements  are  based  on  current  year  2009  CPU  specifications.  The 
Vendor  is  expected  to  provide  CPU's  with  additional  processing  capability  as 
necessary  and  available  throughout  the  term  of  the  contract. 

2)  The  vendor  will  provide  on-site  administrative  training  for  City  employees. 

3)  The  Vendor  may  take  the  City's  existing  IVRS  equipment  (listed  in  section  4.17.3.0)  in 
trade. 

4)  The  Vendor  will  turnover  ownership  rights  to  the  equipment  at  the  termination  of  the 
contract  entered  into  pursuant  to  this  RFP. 
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(4.17.5)  Overview  of  Vendor's  Responsibilities  for  ACD 


The  Vendor,  at  its  cost,  will  be  required  to  install  operate,  manage  and  provide  all  the 
software,  hardware,  programming,  maintenance,  technical  assistance  and  on-going 
support  services  for  a  new  state  of  the  art  Automatic  Call  Distributor  (ACD).  The  City 
requires  a  complete,  high  quality  ACD  with  telephones  at  the  start  of  this  contract.  The 
City  will  be  only  responsible  for  providing  a  location  for  the  hardware  within  the 
BTD/OPC  City  Hall  office  and  the  provision  of  the  telephone  lines  used  by  customers  to 
access  the  ACD  and  Interactive  Voice  Response  System  (IVRS).  The  ACD  must  be 
totally  compatible  with  the  Vendor  provided  IVRS.  The  equipment  provided  by  the 
Vendor  must  be  a  current  state-of  the-art  version  of  the  existing  Definity  G3si  Automatic 
Call  Distributor.  The  current  equipment  was  purchased  in  2008.  Proposers  may  and  are 
urged  to  suggest  alternatives  to  the  way  in  which  the  ACD  is  being  utilized,  but  the  City 
will  have  sole  discretion  to  accept  or  reject  suggestions.  The  Vendor  must  maintain  the 
current  ACD  product  and  its  equipment  (including,  at  a  minimum,  3  supervisor  display 
phones,  15  phone  sets  and  supervisor's  CRT  Console)  with  an  expanded  and  state-of-the- 
art  ACD  product  that  will  allow  and  provide  for  growth  and  change.  The  phone  sets  will 
have  the  capability  of  being  used  with  handsets  and  headsets.  It  will  be  up  to  the  City's 
discretion  to  utilize  wireless  headsets.  Presently,  on  hold  music  is  being  provided  by  way 
of  a  portable  compact  disc  (CD)  player.  Proposers  must  provide  an  alternative  to  the  CD 
player.  The  Vendor  must  provide  on-site  support  via  fully  trained  local  staff.  The 
vendor,  at  its  cost,  will  maintain  on-site  service  agreement  for  the  hardware  and  software 
for  the  ACD. 


(4.17.5.1)  Current  System  Configuration 

The  current  system  is  the  Definity  G3si  System  Automatic  Call  Distributor  which  has  the 
capacity  of  more  than  108  ports.  Additional  information  about  the  system  follows: 

Station  Equipment 


2 
2 
2 
1 
1 
1 


3 

15 
1 


Executive  Model  Display  Phones 
CSR  Telephones 

Supervisor's  CRT  Console  allowing  access  to  Management 

Reports  and  System  and  Station  Programming 

Central  Office  Line  Cards 

Station  Cards 

Analog  Cards 

DTMF  Card 

"Advanced"  ACD  Software 
Printer 
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System  Equipment 


1  Cabinet 

1  Modem  for  Remote  Maintenance 

1  DSA  Software 

3  8  port  CO  Trunk  Interface  for  IVR  Traffic 

1  8  port  CO  Trunk  Interface  for  Administrative  Traffic 

1  Announcement  board  and  4MB  Flash  Cartridge 

1  24  port  Analog  Interface 

1  24  port  Digital  Interface 
128  Size  Sensitive  ports 

1  BCMS-VU  and  8400  data  module  for  up  to  5  Supervisors 

1  Call  Center  Elite  software  for  15  agents,  3  supervisors  and  48  VRU 

ports 

2  DS1  for  Line  side  T1.5 

16  6416D+  Voice  Terminals  for  CSRs  and  Supervisors 

1  Music-on-hold  Interface 

1  Magic-on-hold  Interface 


(4.17.5.2)  Minimum  Requirements 

Customer  calls  will  go  directly  to  the  ACD  and  subsequently  routed  to  the  IVRS.  If  any 
lines  within  an  application  are  busy,  callers  will  be  placed  in  queue  with  a  message  and 
music  rather  than  getting  a  busy  signal.  There  will  be  no  busy  signals.  Calls  to  each 
IVRS  line  within  an  application  will  be  distributed  evenly,  as  the  ACD  will  send  a  call  to 
the  first  available  line  within  the  IVRS  application.  When  a  customer  chooses  the  option 
to  speak  to  a  Customer  Service  Representative  (CSR),  the  ACD  will  assign  the  call  to  the 
first  available  CSR.  If  all  CSRs  are  busy  the  ACD  will  place  the  caller  in  a  queue,  with 
continuous  music,  and  send  the  call  to  the  next  available  CSR.  The  City  will  require  the 
Vendor  to  provide  an  ACD  unit  that  supports  Computer/Telephony  Integration 
(CTI)  and  the  ability  to  adapt  to  digital  communications. 

The  Vendor  will  supply  a  recording  device  to  record  all  CSR  conversations.  This  device 
will  allow  supervisors  to  search  for  and  listen  to  past  calls  and  live  calls.  The  City  will 
require  that  recordings  be  kept  for  at  least  ninety  (90)  days  and  be  retrieved  in  a  trouble- 
free  manner 

The  following  are  the  minimum  hardware  requirements: 

Media  Server 
Service  Ports 
USB  Ports 

Dual  10/100  Base-T  Ethernet  Switch  Ports 
Console  Connection  for  on-site  administration 
A  30GB  hard  disk 
512MB  Ram 
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4.18 

AUTOMATED  REFUND  SYSTEM 
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(4.18)  AUTOMATED  REFUND  SYSTEM 


The  Vendor  shall  provide  an  on-line  real  time  refund  system  which  shall  interface  with 
the  City's  automated  refund  system.  The  Vendor  shall  be  required  to: 

a)  Reapply  the  refund  amount  against  other  outstanding  tickets  as  well  as  fees 
(i.e.,  boot  fees,  storage  fees,  etc.),  in  accordance  with  payment  reapplication 
policies  established  by  the  City; 

b)  Record  the  refund  and  refund  amount  against  the  master  violations  file  and 
archive  file; 

c)  Produce  a  refund  file  on  magnetic  tape  for  City  Treasury  Department  process 
of  checks; 

d)  Generate  report  by  name  in  alphabetical  order  of  all  refund  transactions  on 
magnetic  tape  with  dollar  amount  of  each  refund  and  tape  total;  and 

e)  Produce  refund  transactions  by  way  of  File  Transfer  Process  (FTP)  for  the 
interface  with  City  of  Boston  accounts  payable  system. 
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4.19 

MANAGEMENT  INFORMATION  SYSTEM 
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(4.19)  MANAGEMENT  INFORMATION  SYSTEM 


(4.19.0)  Comprehensive.  Detailed.  Accurate  and  Timely  Management  Tools 

In  addition  to  other  reporting  requirements  set  forth  in  this  RFP,  the  Vendor  shall 
provide  the  issuance,  noticing,  financial,  operational,  accounting,  management,  control 
and  other  reports  that  are  required  by  the  City  for  the  administration  of  the  PVPMISS, 
the  execution  of  its  responsibilities  and  monitoring  of  the  performance  of  the  Vendor. 
The  data  and  information  needs  of  City  management  require  wide  ranging, 
comprehensive,  detailed,  accurate,  timely  and  functionally  integrated  reports. 

The  Vendor  shall  deliver  to  the  City  all  such  reports  within  one  workday  of  their 
specified  computer  run  dates. 

The  City  retains  the  right  at  all  times  to  modify  or  enhance  its  reporting  requirements. 

Following  are  some  examples  of  the  types  of  reports  required  for  the  City  management. 
These  examples  are  not  intended  to  represent  the  total  reporting  needs  of  City 
management. 


(4.19.1)  Management  and  Operational  Reports  for  Violation  Issuance: 

a)  VIOLATION  DISTRIBUTION  REPORT  -  A  monthly  report  that  provides  a 
fiscal  year-to-date  breakdown  of  the  number  of  each  type  of  violation  issued 
(along  with  the  violation  code)  by  agency,  and  the  percentage  of  that  violation 
type  to  the  total  (as  a  percentage  of  total  issuance). 

b)  VIOLATION  DISTRIBUTION  BY  MONTH  -  NUMBER  OF  VIOLATIONS 
—  A  monthly  report  that  provides  a  fiscal  year  to  date  count  of  each  type  of 
violation  and  violation  code  issued  by  month,  with  the  complete  fiscal  year  by 
month  displayed  across  a  single  page. 

c)  ISSUANCE  AND  ERROR  BY  DIVISION  -  A  monthly  report  that  analyzes 
by  number  and  percentage  an  issuing  agent's  monthly  performance  with  a 
breakdown  by  agency,  division  and  individual  badge  number,  highlighting 
missing  data  fields  (ex.  no  time,  no  make,  no  location) 

d)  ISSUANCE  AND  ERROR  EXCEPTION  REPORT  -  A  monthly  report  for  the 
current  month,  run  off  the  Issuance  and  Error  Report  (see  above),  that  reflects 
by  division  and  badge  number  those  issuing  agents  whose  error  rate  is  two  and 
a  half  times  the  average  error  rate  for  that  division. 

e)  TIME  ISSUANCE  REPORT  -  A  monthly  report,  also  run  off  the  Issuance  and 
Error  Report,  that  further  breaks  down  issuance  by  time  for  a  twenty-four  hour 
period  in  two  hour  segments,  for  the  report  month. 
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f)  MONTHLY  WEEK  BY  WEEK  BREAKDOWN  --  A  monthly  report,  also  run 
off  the  Issuance  and  Error  Report,  that  further  breaks  down  issuance  by  weekly 
segments  of  the  report  month. 

g)  ISSUANCE  AND  DISMISSAL  REPORT  BY  DIVISION  --  A  monthly  report, 
for  fiscal  year-to-date  that  analyzes  by  number  and  percentage  of  violations 
issued  (by  agency  and  badge  number)  the  subsequent  dismissal  activity  per 
fiscal  year-to-date  identified  by  one  of  the  fourteen  dismissal  codes; 
63=hearing  dismissal,  71=incomplete  ticket,  72=valid  resident  permit,  etc. 

h)  OUT  OF  STATE  ISSUANCE  ACTIVITY  BY  STATE  -  A  monthly  report, 
for  fiscal  year-to-date,  of  out-of-state  violation  issuance  with  fine  and  penalty 
amounts  by  individual  state  with  subsequent  payment  activity  which  includes 
the  number  of  tickets  fully  and  partially  paid,  the  dollar  amount  collected,  and 
the  last  notice  sent  with  the  notice  type  and  count  reflected. 

i)  ISSUANCE  BY  ROUTE/AREA  -  A  monthly  report  that  displays  the  number 
of  violations  issued  by  violation  category  by  area/route. 


(4.19.2)  Financial  Management  and  Operational  Reports 

a)  PARKING  VIOLATION  COLLECTION  REPORT  -  A  monthly  report  of  the 
total  dollars  collected  by  month  for  the  current  month  and  the  last  13  months 
from  regular  violation  payments,  booting  activities,  violation  tows,  storage 
fees,  tow  fees,  rental  surcharges,  bounced  check  fees  and  abandoned  vehicle 
payments.  This  report  also  provides  the  fiscal  year-to-date  totals  for  each 
category  as  well  as  the  overall  totals  for  the  last  12  months. 

b)  PAYMENT  BY  VIOLATION  TYPE  -  A  semi  annual  report  of  fiscal  year 
violations  issued,  by  violation  type,  with  number  of  tickets  paid  and  the  dollar 
amount  paid,  as  well  as  the  number  of  unpaid  tickets  and  the  total  dollar 
amount  due. 

c)  PAYMENT  BY  FISCAL  YEAR  OF  ISSUANCE  -  A  semi  annual  report  of 
the  total  amount  collected  in  the  current  fiscal  year  which  summarizes  the  total 
number  of  tickets  with  payments  and  the  dollar  value  of  those  payments  as 
applied  to  tickets  issued  in  the  current  and  prior  fiscal  years. 

d)  AGED  TICKET  PAYMENT  REPORT  -  A  semi  annual  report  of  monthly 
payments  collected,  the  number  of  violations  paid  and  the  percentage  stratified 
by  the  age  of  the  violation. 

e)  AGED  PAYMENT  WITH  ASSOCIATED  LAST  NOTICE  -  A  monthly 
report  that  tracks  tickets  issued  one  year  ago  with  the  number  and  dollar 
amount  of  the  violations  paid,  from  the  issuance  month  to  the  current  report 
month.  This  report  also  indicates  the  last  notice  associated  with  the  payment. 
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f)  AGED  RECEIVABLES  REPORT  -  A  semi  annual  report  of  unpaid  violations 
categorized  by  the  age  of  the  violations,  for  Massachusetts,  Out-Of-State  and 
All  violation  issuance  totals.  Violations  are  categorized  in  the  report  by  age  of 
issuance. 

g)  RECEIVABLES  BY  FISCAL  YEAR  --  A  monthly  report  of  Massachusetts, 
Out-Of-State  and  All  violation  issuance  totals,  and  the  amount  due  in  fines  and 
penalties,  for  the  current  fiscal  year  and  at  least  seven  prior  fiscal  years. 

h)  OPEN  NOTICED  VIOLATIONS  REPORT  --  A  semi  annual  report  for  Mass. 
and  Out-Of-State  violations  that  indicates  the  number,  percentage  and  dollar 
amount  of  opened  tickets  for  each  of  the  last  three  years  and  identifies  the  last 
notice  sent  on  these  tickets. 

i)  FULL  AND  PARTIALLY  PAID  VIOLATIONS  REPORT  -  A  semi  annual 
report  for  Mass.  and  Out-of-State  violations  that  indicates  the  number, 
percentage  and  dollar  amount  of  full  and  partially  paid  tickets  for  the  last  three 
years  and  identifies  the  last  notice  sent  that  was  associated  with  the  payment. 

j)    ISSUE  DATE  VERSUS  PAYMENT  DATE  REPORT  -  A  semi  annual  report 
that  indicates,  for  specified  time  periods,  the  number  and  percentage  of  tickets 
paid  within  a  particular  category  of  days  from  the  issue  date  of  the  ticket  and 
identifies  from  what  notice  payment  was  made. 

k)    AUDIT  REPORT  ON  PLATE  STATE  -  A  semi  annual  report  by  calendar  and 
fiscal  year  which  identifies  states  (in  descending  order  by  those  with  the  largest 
ticket  issuance),  the  plate  counts  and  the  accumulated  percentage  of  tickets 
issued  by  state  from  the  state's  percentage  of  total  tickets  issued.  This  report 
also  indicates  all  open  tickets  for  each  state,  the  percentage  of  open  tickets  for 
each  state  and  the  total  dollar  amount  due.  This  report  should  include  archived 
tickets. 

1)    ISSUANCE  ANALYSIS  REPORT  -  A  semi  annual  report  by  calendar  and 
fiscal  year  which  indicates  for  Mass.,  Out-Of-State  and  all  combined  violations 
the  total  number  of  tickets  issued  with  the  total  plates  and  identifies  for  this 
population:  the  number  of  unpaid  tickets,  the  percentage  of  unpaid  tickets  from 
total  issuance  and  the  $$  amount  due  for  the  issue  year. 

m)  SCOFFLAW  ANALYSIS  REPORT  -  A  semi  annual  report  by  calendar  and 
fiscal  year  which  provides  a  break-down  of  plates  categorized  by  the  number 
of  tickets  issued,  the  percentage  of  plates  that  were  issued  a  specific  number  of 
tickets,  the  actual  ticket  count  and  the  percentage  of  the  total  number  for  that 
ticket  count  category.  This  report  also  indicates  the  number  and  total  dollar 
amount  of  unpaid  tickets  for  this  population  and  the  percentage  of  unpaid 
tickets  from  the  total  ticket  count  categories. 
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(4.19.3)  Dunning  Notice  Management  and  Operational  Reports 

a)  OPEN  UNNOTICED  VIOLATION  REPORT  -  A  monthly  report  of  Mass., 
Out-Of-State  and  All  violation  issuance  totals  for  the  past  36  months, 
categorized  by  monthly  issue  period,  that  indicates  the  total  monthly  issuance 
and  the  amount  due,  for  unpaid  unnoticed  tickets,  the  monthly  count,  amount 
due  and  the  reason  for  not  noticing  such  as:  special  plate,  make  mismatch, 
registry  no  match  and  other. 

b)  ACTIVITY  SUMMARY  FOR  FISCAL  YEAR  --  A  semi  annual  summary 
report,  fiscal  year-to-date,  that  provides  the  total  number  of  violations  issued, 
the  number  noticed  by  notice  type,  the  number  not  noticed  and  the  percentage 
of  tickets  issued  that  were  not  noticed.  This  report  provides  this  information 
for  the  report  month,  the  fiscal  year-to-date  including  the  report  month  and  the 
fiscal  year-to-date  excluding  the  report  month. 

c)  ANALYSIS  OF  NAMES  AND  ADDRESSES  APPLIED  VERSUS 
OVERDUE  NOTICE  EXTRACT  -  A  weekly  report  that  provides  the  number 
of  tickets  associated  with  the  name  and  address  returns  from  the  Registry  of 
Motor  Vehicles.  The  total  tickets  with  name  and  address  returns  are  broken 
down  by  those  tickets  mailed  an  initial  Overdue  notice  and  those  tickets  not 
noticed,  including  ticket  and  plate  statistics  and  a  breakdown  of  reasons  for  not 
noticing,  such  as:  full  payments,  dispositions,  suspensions,  nixies,  registry  no 
hits,  no  confirm  dates,  etc.  The  registry  no  hit  errors  are  further  broken  down 
by  reason  with  the  count  and  percentage  of  the  total  errors.  This  report 
provides  a  sampling  of  violations  identifying  the  reasons  for  not  noticing  with 
a  reason  code,  the  state  plate,  the  ticket  number  and  issue  date  if  applicable, 
the  RMV  and  ticket  vehicle  makes  and  the  next  system  scheduled  action  date. 


(4.19.4)  Other  Management  and  Operational  Reports: 

a)  MASS  AND  OUT  OF  STATE  SUMMARY  STATUS  REPORT  -  A  monthly 
report  of  Mass.,  Out-Of-State  and  All  violation  issuance  totals  by  month  of 
issuance  (for  a  thirty-six  month  period)  summarily  categorizing  payment  and 
dismissal  activity  by  closed  violations  and  the  listing  of  open  violations 
statuses.  The  report  provides  information  for  closed  tickets  and  indicates  the 
number  of  tickets  which  were  fully  dismissed,  partially  dismissed,  fully  paid, 
partially  paid  and  the  ticket  count  and  dollar  amount  paid.  For  open  tickets, 
the  reports  provides  information  on  which  tickets  were  noticed/unnoticed  and 
which  were  totally  unpaid  or  partially  unpaid  with  the  ticket  count  and  dollar 
amount  owed. 

b)  MASS  NON-RENEWAL  SUBSYSTEM  REPORT  -  A  monthly  report  that 
summarizes  (fiscal  year-to-date)  the  Registry  of  Motor  Vehicles'  Clearing 
Transaction  Report  and  provides  information  by  month  on  the  total  number  of 
marks,  chargeable  clears  and  free  clears.  The  report  also  identifies  the 
beginning  balance  and  closing  balance  for  the  month  and  the  fiscal  year-to-date 
total. 
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c)  DISPOSITION/CORRESPONDENCE  ANALYSIS  REPORT  --  A  monthly 
report,  fiscal  year-to-date,  that  analyzes  the  breakdown  of  violation  dismissals 
and  correspondence  analysis,  which  are  broken-down  by  disposition  code  and 
description.  The  number  of  tickets,  the  dollar  amount  reduction,  and  the 
percentage  of  the  total  tickets  reduced  for  each  code  are  identified. 

d)  SWAP  REPORT  —  A  monthly  report  of  the  valid  swap  transactions  by 
category  and  total  for  the  current  month.  This  report  also  includes  a  break- 
down by  category  of  all  SWAP  transactions  with  the  current  plate,  expired 
plate  and  the  effective  date,  plate  type,  registered  owner's  name,  date  of  birth 
and  driver's  license  number  for  both  plates. 

0 

e)  TOP  VIOLATORS  REPORT  -  A  report  run  on  request  that  identifies  those 
violators  who  owe  a  designated  amount  or  more  in  violation  fines  and  penalties 
for  tickets  issued  within  the  past  two  years  or  for  specific  time  parameters.  This 
report  includes  but  is  not  limited  to  registrant  name,  address,  vehicle  make, 
state  plate  and  total  dollar  amount  due. 

f)  TOP  VIOLATOR  ACTIVITY  REPORT  -  A  report  run  on  request  that 
provides  statistics  on  the  top  violator  populations  for  a  specific  time 
parameter,  such  as:  payment  activity,  scheduled  hearings,  suspends, 
correspondence  received  and  noticing  activity. 

g)  ISSUANCE  BY  ZIP  CODE  REPORT  -  A  yearly  report  which  provides 
information  on  relative  percentage  of  violations  issued  to  Mass.  and  Out-of- 
State  plates.  For  Mass.  tickets,  the  report  provides  relative  percentage  of 
violations  issued  to  approximately  eight  zip  code  groupings  within  the  City  of 
Boston.  Report  is  formatted  to  facilitate  comparisons  between  years. 


(4.19.5)  Audit  and  Control/Transaction  Update  Reports: 

The  Vendor  shall  be  required  to  provide  audit  and  control  reports.  These  reports 
must  be  generated  daily,  weekly,  and  monthly  and  to  the  extent  possible  should  be 
done  in  an  automated  fashion.  These  reports  must  include,  by  way  of  example  and 
without  limitation,  the  following  features: 

-  the  number  and  type  of  all  transactions  processed  together  with  associated  dollar 
values  (the  processing  of  skeleton  transactions  must  be  accounted  for  in  addition 
to  the  subsequent  update  of  an  existing  skeleton  transaction  to  a  'real' 
transaction) 

-  an  accounting  of  any  and  all  rejected  transactions  and  their  subsequent  handling 

-  the  segregation  of  all  transactions  by  batch  or  on-line  category 

-  a  reporting  of  system  generated  activities  (such  as  the  application  of  penalties) 

-  a  statement  of  gross  and  net  income  of  the  parking  ticket  system 

-  a  reconciliation  of  cash  deposits  and  payments  recorded  against  the  Master 
Violations  File 
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-  a  summary  of  changes  in  the  values  of  accounts  receivable  balances 

-  a  summary  of  overpayments  in  state-plate  order  by  citation  number  with 
associated  dollar  values. 


The  system  must  also  provide  detailed  audit  trails  of  every  transaction  that  is 
recorded  against  the  Master  Violations  File  and  these  audit  trails  must  permit  a 
reconciliation  of  all  transactions  against  their  associated  source  documents. 


(4.19.6)  Ticket  Management  Information  System: 

The  Vendor  will  be  required  to  provide  a  complete  and  comprehensive  set  of 
reports  relating  to  the  distribution  and  issuance  of  tickets.  The  Ticket  MIS  must 
track  the  issuing  agency  and  division  that  has  received  ticket  blanks  from  inventory 
and  assign  skeletal  or  unapplied  transactions  and  missing  tickets  to  the  responsible 
agency,  division  and  applicable  badge  number. 


(4.19.7)  Report  Format  /  Media 

The  Vendor  will  be  required  to  produce  any  and/or  all  reports  via  hardcopy  and 
other  media  requested  by  the  City.  Also,  the  Vendor  must  allow  City  personnel 
to  produce  ad  hoc  reports  from  desktop  workstations. 
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4.20 

PRODUCTION  SCHEDULES 
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(4.20)  PRODUCTION  SCHEDULES 


The  Vendor  shall  prepare  a  detailed  monthly  production  schedule  that  includes  by  way 
of  example  and  is  not  limited  to  the  following  planned  activities: 

file  processing 

report  generation,  such  as  scheduled  management  information  reports,  on-line 
claims  processing  related  reports,  and  all  scheduled  reports  relative  to  any 
systems,  subsystems  or  system  elements  for  which  the  Vendor  is  responsible 

transaction  cutoff  periods 

notice  mailing 

Massachusetts  RMV  name  and  address  request  transactions 

Massachusetts  RMV  name  and  address  re-request  transactions 

Massachusetts  RMV  mark  request  transactions 

Massachusetts  RMV  mark  re-request  transactions 

Massachusetts  RMV  clear  request  transactions 

Massachusetts  RMV  clear  re-request  transactions 

Boot  and  Tow  System  seizure  eligible  list  (boot  book  in  hard  copy  and 
machine  readable  form) 


Such  schedules  shall  be  delivered  to  the  City  at  least  ten  (10)  days  before  the  beginning 
of  the  month  of  scheduled  production. 

The  City  may  also  require  the  Vendor  to  provide,  no  later  than  two  weeks  following 
each  preceding  month,  a  report  of  actual  production  activity.  This  report  would  serve  as 
a  follow-up  to  the  planned  production  schedule  indicating  any  deviations  and  the 
reasons  for  such  deviations  from  the  planned  schedule. 
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4.21 


NETWORK  CAPABILITY  AND  OTHER  EQUIPMENT.  SERVICE  AND 

SUPPLY  REQUIREMENTS 
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(4.21)  NETWORK  CAPABILITY  AND  OTHER  EQUIPMENT. 
SERVICE  AND  SUPPLY  REQUIREMENTS 


f4.21.01  Overview 

The  Vendor  shall  provide  the  City,  at  a  minimum,  with  the  following  network 
capability,  equipment  and  related  items  to  be  located/connected  at  City  of  Boston 
locations.  The  Vendor  will  bear  all  direct  and  related  costs  of  purchasing  or  leasing, 
maintaining  and  servicing  such  network  capability  and  equipment  as  well  as  for 
providing  all  related  supplies  and  materials  such  as  licenses,  UPS',  cables,  ribbons  and 
paper. 


(4.21.1)  Detailed  Requirements 

a)    The  Vendor  must  implement  and  maintain  the  entire  data  communication 
network  (with  the  exception  of  the  City's  City- wide  internal  network)  that 
supports  all  PVPMISS  and  related  personal  computers,  terminals, 
workstations,  printers,  and  all  devices  located  in  City  offices  that  require 
access  to  the  Vendor's  PVPMISS,  to  other  databases  directly  or  indirectly 
supported/provided  by  the  Vendor  or  accessed  via  the  Vendor,  and  download 
and  upload  data  as  required.  All  communications  capabilities  and  modes 
provided  by  the  Vendor  should  consist,  at  a  minimum,  of  dedicated  high-speed 
digital  circuits  to  each  City  location,  with  dedicated  back-up  capability  in  the 
event  of  line  failure  and  trouble-shooting  help  for  City  users. 

The  Vendor  will  be  required  to  coordinate  and  interface  with  the  City  Network 
as  required  by  the  City's  MIS  Department.  This  includes  any  upgrades  to  the 
City  network  during  the  contract  term.  The  Vendor  must  fully  support  a 
working  relationship  with  the  City  relative  to  interfacing  and  coordinating 
functions  involving  the  Local  and  Wide  Area  Network(s)  that  the  City  has 
installed  at  different  locations  as  most  users  will  be  connected  to  the  City's 
internal  Network.  The  City's  Network  currently  utilizes  Microsoft 
NT/Windows9X  and  subject  to  upgrades.  However,  the  Vendor  should 
recognize  that  the  City  will  likely  require  that  some  Personal  Computers  and 
other  devices  such  as  those  utilized  for  cashiering  and  correspondence  work 
flow  be  interfaced  solely  with  the  PVPMISS  (and  not  routed  through  the  City 
network). 

The  Vendor  must  have  back-up  options  to  provide  direct  access  to  the 
PVPMISS  without  connecting  via  the  City's  or  Vendor's  network.  The 
Vendor  will  also  be  required  to  provide  access  to  its  databases  from  a  limited 
number  of  non-primary  PVPMISS  devices,  estimated  to  be  100,  connected  to 
the  City's  networks.  The  Vendor  will  be  responsible  for  its  costs  related  to 
these  connections.  If  the  City's  network  fails,  access  to  the  Vendor's  network 
must  be  maintained.  In  the  case  of  the  Vendor's  network  failing,  the  Vendor 
must  provide  immediate  access  to  the  PVPMISS  for  all  customer  service 
workstations. 
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The  City's  responsibilities  are  limited  to  only  maintaining  its  Personnel 
Computers  and  printers  that  have  been  purchased  by  the  City  for  its  employees 
whose  primary  duties  are  to  utilize  the  PVPMISS  at  various  City  locations. 
The  City  will  only  be  responsible  for  the  physical  items  which  will  be  limited 
to  the  actual  Personal  Computer,  printer  and  the  cable  to  a  hub  or  other  such 
equipment  if  physically  located  at  the  City  site.  The  Vendor  will  retain  full 
responsibility  and  must  fully  support  the  operation  of  these  devices  in  all  other 
regards  including,  but  not  limited  to,  all  connectivity  to  the  PVPMISS,  and  all 
hardware,  software,  telecommunications,  etc.  involving  the  Vendor's 
PVPMISS,  other  databases  directly  or  indirectly  supported/provided  by  the 
Vendor  or  accessed  via  the  Vendor  (i.e.,  the  Registry  of  Motor  Vehicles 
database)  unless  precisely  specified  otherwise.  Some  devices  in  this 
population  will  be  utilized  for  tasks  and  functions  in  addition  to  PVPMISS 
related  tasks  and  functions,  such  as  word  processing,  spreadsheet  applications, 
charting  and  graphics  programs,  etc.  Therefore,  the  Vendor  must  fully  support 
the  simultaneous  access  to  a  variety  of  applications  in  accordance  with 
performance  standards  specified  in  this  RFP. 

Currently,  the  City  has  employees  located  at  the  OPC  at  City  Hall,  using 
approximately  eighty- five  (85)  work  stations  (Personal  Computers  [Pentium's 
with  super  VGA  17",  19"  and  21"  monitors,  and  memory  upgrades]  or  higher- 
end  workstations)  including  monitors  with  shared  or  independent  printers  for 
primarily  accessing  and  entering  information  to  the  Vendor's  PVPMISS 
databases,  computer  files,  imaging  and  other  applications  required  as  part  of 
this  RFP.  Twenty-five  to  thirty  (25-30)  additional  similar  devices  are  located 
at  other  BTD  City  Hall,  Tow  Lot  and  Operations  Division  locations.  The  City 
shall  provide  the  Vendor  with  a  plan  of  the  locations  where  such  devices  are  or 
will  be  installed.  At  present,  workstations  are  located  on  five  different  floors  at 
City  Hall  and  at  two  Transportation  Department  off-site  locations  (the  Tow  Lot 
and  the  Operations  Division). 

The  Vendor  will  be  required  to  provide  the  capability  and  all  resources 
including  licenses  to  allow  the  City  to  utilize  additional  primary  PVPMISS 
Personal  Computers  or  similar  devices  on  an  as  need  basis.  At  this  time,  the 
City  is  not  planning  to  add  more  than  thirty-five  (35)  devices.  However,  if  the 
need  arises  due  to  ticket  issuance  increases  or  programmatic  reasons,  this 
number  is  subject  to  change.  If  issuance  remains  below  1,900,000  parking 
tickets,  the  City  may  commit  to  limiting  its  usage  to  no  more  than  150  Personal 
Computers,  peripheral  devices  and  all  related  equipment,  materials  and 
supplies  that  would  be  considered  to  be  directly  part  of  the  primary  PVPMISS 
operation.  The  Vendor  should  be  aware  that  access  for  non-primary  users 
through  the  City  and  Vendor  networks  by  other  Personal  Computers  or  other 
devices  to  the  PVPMISS  and  other  provided  applications  as  required  by  this 
RFP  must  be  made  available.  However,  the  Vendor  will  not  be  required  to 
assume  responsibility  and/or  provide  support  for  these  devices. 

As  noted,  any  and  all  server  workstations  or  equipment  installed  at  a  City 
location  and  utilized  as  part  of  the  PVPMISS  provided  by  the  Vendor  shall 
become  the  complete  responsibility  of  the  Vendor. 
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c)  Cashiering 

Six  (6)  personal  computers  and  three  (3)  fully  configured  back-up  devices 
(back-up  devices  shall  be  located  at  the  Vendor's  local  office)  to  the  PVPMISS 
shall  be  specifically  designed  as  PVPMISS  cashiering  terminals  to  provide  the 
On-Line/Real-Time  Payment  Processing  services  described  in  this  RFP. 

d)  All  of  the  communications  lines,  controllers,  modems,  modem  controllers, 
routers,  bridges  and  other  telecommunication  devices  as  may  be  required  to 
operate  the  work  stations,  equipment  and  systems  that  are  required  to  be 
provided  herein  by  the  Vendor.  This  would  include  any  and  all  licenses. 

e)  The  Vendor  shall  provide  at  the  time  of  installation  and  on  an  ongoing  and  as- 
need  basis  technical  assistance  as  may  be  necessary  to  install,  configure  and 
operate  all  PVPMISS  related  devices,  whether  Vendor  or  City  provided,  to 
allow  for  maximum  efficiency  of  City  workspace.  This  could  include  the 
usage  of  "zero  footprint"  PCs. 

f)  Two  microfilm  readers/printers  (Microfilmer  Scanner  400).  The  Vendor  shall 
also  provide  for  the  service  of  such  reader  and  provide  all  supplies  (excluding 
paper)  required  for  the  operation  of  such  equipment. 

g)  In  addition  to  the  equipment  and  supplies  specified  herein: 

for  each  100,000  (one  hundred  thousand)  tickets  issued  in  excess  of  1,600,000 
(one  million,  six  hundred  thousand),  the  Vendor  shall  provide,  at  the  City's 
discretion,  two  (2)  fully  equipped  Personal  Computer/workstations  ,  two  (2) 
printers  and  all  applicable  lines,  modems,  controllers  and  telecommunication 
devices  as  may  be  required  to  operate  such  additional  equipment. 

Additional  cashiering  devices  shall  be  provided  in  accordance  with  the 
specifications  contained  in  Section  4.7.4  of  this  RFP. 


(4.21.2)  WWW  /  Internet  Applications 

The  Vendor  will  be  required  to  provide  the  Parking  Clerk  with  an  integrated  web-based/ 
Internet  applications  for  customer  service  transactions  and  programs.  Such  applications 
will  supplement  existing  customer  service  applications  provided  by  the  Vendor  as  part 
of  the  Vendor's  PVPMISS.  This  may  include  the  Vendor's  Resident  Parking  Permit 
System,  the  Lease/Fleet  Vehicle  System,  the  Correspondence  Imaging  Workflow 
System  including  the  Hearing  component  of  such  system,  etc. . .  The  Vendor  will  be 
required  to  provide  all  application  software,  support  and  maintenance  for  Internet 
applications.  The  Vendor  will  be  required  to  provide  access  to  such  applications  via  the 
City  of  Boston's  website  (www.cityofboston.gov). 

NOTE:  The  City  will  likely  distribute  additional  specifications  relative  to  this  scope  of 
services  item  via  addendum. 

Also  note  that  the  City  may  require  the  Vendor  to  develop  a  'Hearing  by 
Internet'  pilot  program.  This  would  involve  installing  one  work  station  in  the 
Hearing  Unit  that  would  enable  the  processing  of  hearings  using  a  Web  Cam. 
All  equipment  and  processes,  including  software  and  testing  will  be  the 
responsibility  of  the  Vendor. 
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(4.21.3)  Network.  Communications  and  Hardware  Specifications 


The  Vendor  must  provide,  as  part  of  its  RFP  submission,  a  document  that  lists  and 
confirms  the  selection  of  hardware,  software,  telecommunications  lines,  communication 
lines  and  related  equipment  and  items.  Such  document  should  also  provide  a  detailed 
configuration  of  the  communication  network  and  location  of  all  equipment  and  fully 
describe  the  Vendor's  redundant  system  capability,  back-up  system  capability  and 
remote  monitoring  and  recovery  capabilities.  The  selected  Vendor  must  provide,  after 
the  awarding  of  the  contract,  a  document  describing  the  terms  of  maintenance  plans  that 
covers  all  of  the  hardware,  software,  telecommunication  lines,  communications  lines 
and  related  equipment  and  items  cited  in  this  section  (4.21). 

(4.21.4)  Additional  Services/Equipment/Supplies  Requirements 
and  Procurement  Thereof 

In  addition  to  the  equipment  and  supplies  specified  in  Section  4.0  herein  and  in 
accordance  with  applicable  procurement  laws,  the  City  may  require  the  Vendor  to 
procure  other  equipment,  supplies  and  services  through  purchase  or  lease  for  use  or 
ownership  by  the  City  which  are  needed  to  implement  the  terms  and  conditions  of  the 
contract  entered  into  pursuant  to  this  RFP.  The  City  shall  reimburse  the  Vendor  for  the 
actual  cost  of  such  other  services,  which  shall  be  in  addition  to  the  basic  reimbursement 
schedule.  The  Vendor  is  not  allowed  to  charge  the  City  for  any  administrative  or 
overhead  charge/cost  in  regards  to  such  procurements. 

(4.21.5)  Replacement  of  City  Owned  Personal  Computers.  Monitors.  Laser  Printers 

The  Vendor  will  replace  up  to  thirty-five  (35)  personal  computers,  including  monitors, 
currently  owned  by  the  City,  within  the  term  of  this  contract.  Also,  the  Vendor  will 
replace  fifteen  laser  printers  ,  currently  owned  by  the  City,  within  the  term  of  this 
contract.  It  will  be  determined  by  the  City  as  to  which  devices  will  be  replaced.  The 
Vendor  will  retain  full  responsibility  and  must  fully  support  the  operation  of  these 
devices  in  all  other  regards  including,  but  not  limited  to,  all  connectivity  to  the 
PVPMISS,  and  all  hardware,  software,  telecommunications,  etc.  involving  the  Vendor's 
PVPMISS,  other  databases  directly  or  indirectly  supported/provided  by  the  Vendor  or 
accessed  via  the  Vendor  (i.e.,  the  Registry  of  Motor  Vehicles  database)  unless  precisely 
specified  otherwise.  Some  devices  in  this  population  will  be  utilized  for  tasks  and 
functions  in  addition  to  PVPMISS  related  tasks  and  functions,  such  as  word  processing, 
spreadsheet  applications,  charting  and  graphics  programs,  etc.  Therefore,  the  Vendor 
must  fully  support  the  simultaneous  access  to  a  variety  of  applications  in  accordance 
with  performance  standards  specified  in  this  RFP.  Replacement  of  equipment  will 
commence  year  one  of  the  contract  term  and  in  accordance  to  the  operational  needs  and 
discretion  of  the  City.  At  the  City's  discretion  the  selected  Vendor  will  be  responsible 
for  the  disposition  of  any  and  all  replaced  equipment.  This  will  include  but  not  be 
limited  to  relocation  and/or  removal. 

(4.21.6)  Location  of  LAN/WAN  Equipment 

The  equipment  used  to  operate  the  PVPMISS  LAN/WAN  (servers,  modems,  etc)  may 
be  located  at  a  City  site  or  the  Vendor's  site  with  the  understanding  that  City  personnel 
will  require  routine  access  to  the  equipment.  The  Vendor  will  make  a  proposal  as  to 
where  the  equipment  may  be  located  to  achieve  optimal  results.  The  final  decision  will 
be  the  City's. 
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(4.22)  ON-LINE  SYSTEM  AVAILABILITY  AND  RESPONSE  TIME 


(4.22.0)  Importance  of 

THE  IMPORTANCE  TO  THE  CITY  OF  THE  CONSISTENT  AND 
UNINTERRUPTED  ON-LINE  AVAILABILITY  OF  THE  PVPMISS,  AND  A 
CONSISTENTLY  RAPID  RESPONSE  TIME  TO  ACCESS  DISCRETE  RECORDS 
OR  RELATED  DATA  ELEMENTS  WITHIN  A  PARTICULAR  RECORD,  CANNOT 
BE  OVERSTATED.  The  following  requirements  should  be  considered  minimum 
requirements. 


(4.22.1)   System  Availability 

All  on-line  systems  shall  be  available  to  the  city  during  the  following  hours: 

-     For  City  Hall 

8:00  A.M.  to  10:00  P.M.,  Monday  through  Friday 

For  the  Tow  Lot  (Frontage  Road) 

5:00  A.M.  to  3:00  A.M.,  i.e.,  22  hours,  Monday  through  Friday 
5:00  A.M.  to  12:00  Midnight,  Saturday;  to  be  reestablished  at  11:PM 
Sunday. 

The  Vendor  shall  maintain  an  aggregate  on-line  system  uptime  of  not  less  than  95%  of 
available  utilization  time,  and  an  on-line  system  uptime  of  not  less  than  90%  of 
available  utilization  time  of  any  given  working  day. 


(4.22.2)  Response  Time 

The  response  time  when  accessing  a  new  record  from  a  blank  menu-type  screen  (as 
measured  by  the  time  the  'enter',  etc.,  button  is  depressed  by  the  user)  for  all  on-line 
systems  shall  on  the  average  be  less  than  three  to  five  seconds. 

The  response  time  when  scrolling  (from  screen  to  screen)  within  a  particular  record,  or 
when  terminating  an  inquiry  from  a  particular  record  so  as  to  revert  to  a  blank  menu- 
type  screen,  should  be  nearly  instantaneous. 
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(4.22.3)  Other  Requirements 


The  Vendor  shall  notify  all  City  departments  which  utilize  its  on-line  systems  of 
occurrence  of  all  downtime  and  shall  report  to  such  department  the  causes  and  expected 
duration  of  such  downtime  and  the  remedial  measures  being  undertaken.  The  City  shall 
provide  to  the  Vendor  a  list  of  the  department  and  persons  to  be  notified  and  the 
appropriate  telephone  numbers.  The  Vendor  shall  also  notify  the  City  of  any 
foreseeable  or  anticipated  downtime  at  least  one  hour  before  such  downtime  is  to  occur. 

The  Vendor  shall  maintain  a  daily  log  of  system  downtime  and  shall  furnish  the  City 
with  a  monthly  downtime  summary. 

The  Vendor  shall  respond  within  thirty  (30)  minutes  of  a  reported  equipment  or 
software  failure  by  providing  the  on-site  technical  support  at  the  City's  premises  as  may 
be  required.  In  instances  of  repeated  system  failures,  the  City  may  require  that  the 
Vendor  provide  on-site  technical  support  on  a  full-time  basis  until  the  problem  is 
permanently  corrected.  For  equipment  failure  coverage,  the  Vendor  shall  contract  with 
its  equipment  Vendors  and  suppliers  to  obtain  service  agreements  requiring  the  Vendor 
to  respond  within  2  hours  of  a  reported  equipment  failure. 

The  Vendor  shall  maintain  a  daily  log(s)  of  all  communications  interruptions  (i.e., 
server  drops,  operating  system  software  interruptions,  etc.)  and  shall  furnish  the  City 
with  copies  of  said  daily  log(s)  on  a  weekly  basis  accompanied  by  a  weekly  summary  of 
such  communications  interruptions,  the  format  of  which  shall  be  approved  by  the  City. 
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(4.23)  FILE  ARCHIVE 


Not  less  than  180  days  from  the  date  of  payment  in  full  or  other  final  disposition  of  a 
parking  violation,  the  Vendor  may  archive  such  violation  from  the  PVPMISS  for  the 
purpose  of  creating  additional  file  storage  capacity.  The  Vendor  shall  also  be  required 
to  archive  skeletal  records.  As  an  additional  archive  requirement,  the  Vendor,  at  the 
City's  direction,  may  archive  non-final  dispositions  of  parking  violations  from  the 
PVPMISS  for  the  purpose  of  creating  additional  file  storage  capacity  and  processing 
efficiencies. 

The  Vendor  shall,  however,  expeditiously  reflect/retain  all  information  described  in  this 
RFP  on  tape  cartridge  or  other  media  approved  by  the  City  for  auditing  and  reporting 
purposes  The  Vendor  shall  provide  the  capability  for  all  OPC  staff  to  view  via  a  user- 
friendly,  operationally  efficient  and  effective  LAN  application  system,  for  auditing, 
reporting  and  dispute  resolution  purposes,  all  ticket  data  elements  as  defined  by  the  City 
for  the  approximately  25  million  tickets  archived  after  February  1994  including  all 
future  archives.  Archive  data  shall  be  available  via  ticket  number,  vehicle  registration 
and  registrant  name.  (Note:  The  approximately  8  million  tickets  archived  prior  to  1994 
are  available  to  the  City  via  microfiche  files)  The  Vendor  shall  be  able  to  restore  such 
archived  violation  information  for  all  archived  tickets  to  the  PVPMISS  at  the  City's 
direction. 

Upon  archiving  of  violations,  the  Vendor  shall  notate  the  affected  vehicle  registration 
files  with  an  "archive  indicator"  to  be  displayed  through  on-line  inquiry  access. 
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(4.24)  ON-LINE  RESIDENT  PERMIT  PARKING  SYSTEM 


(4.24.0)  Resident  Permit  Parking  Program 

The  Resident  Permit  Parking  Program  (RPP)  was  established  to  reserve  certain 
parking  spaces  in  congested  neighborhoods  for  area  residents  only.  Vehicles  must 
display  a  valid  resident  parking  permit  to  utilize  such  spaces. 

(4.24.1)  On-Line  Resident  Permit  Parking  System 

The  City  shall  require  the  Vendor  to  provide  an  on-line  RPP  System,  integrated  with 
the  Vendor's  core  system.  The  on-line  requirements  for  such  a  system  include,  but 
are  not  necessarily  be  limited  to,  the  capability  to: 

add  new  resident  files  to  the  database 

maintain  resident  permit  data 

renew,  hold,  revoke,  and  reinstate  (reactivate)  permits 
update  all  permit  files,  and 
inquire  into  resident  permit  data. 

(4.24.2)  System  Features 

The  Vendor  is  required  to  provide  additional  features  within  the  RPP  System  that 
include,  at  a  minimum,  the  following: 

generation  of  renewal  notices  and  labels 

generation  of  permit  renewal  denial  letters  and  revocation  notices 

purge/archive  of  and  report  on  data  no 

longer  required  to  remain  on  the  on-line  system 

management,  control,  audit  and  activity 
reports  (may  include  listings  of  resident  permits  by  neighborhood,  by  period  of  time, 
by  name  of  permit  holder,  by  location,  etc.) 
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(4.24.3)  System  Components 


The  on-line  system  must  accommodate,  at  a  minimum,  five  hundred  thousand 
(500,000)  files.  The  system  must  allow  on-line  access  via  name,  permit  number,  a 
system  generated  control  number  and  vehicle  registration  number.  Each  resident  file 
must  include,  at  a  minimum,  the  following  information: 

applicant  name  and  address, 

two  telephone  numbers, 

neighborhood  and  neighborhood  code, 

permit  number, 

permit  year, 

vehicle  registration  number, 

vehicle  make  and  year, 

permit  classification, 

method  of  permit  issuance,  and 

proof  of  residency  submitted. 

Most  data  fields  shall  be  multi-character  alphanumeric.  The  system  shall 
accommodate  on-line  updates  to  all  permit  files.  The  system  must  also  incorporate 
security  features  that  will  restrict  access  to  certain  functions  to  authorized  personnel. 
The  Vendor  shall,  on  request,  cross  reference  permit  address  with  the  Massachusetts 
RMV  database  and  the  PVPMISS  database. 

The  Vendor's  RPP  System  shall  accommodate  the  issuance  of  "temporary"  or  ad-hoc 
permits  issued  for  the  limited  or  finite  periods  of  time.  Such  permits  may  be 
supplemental  to  existing  neighborhood  programs  or  may  represent  new  neighborhood 
areas. 

Currently,  the  City  distributes  Resident  Permits  free  of  charge.  The  Vendor's 
system,  however,  shall  accommodate  the  payment  of  a  fee  for  resident  permits  via  the 
Vendor's  PVPMISS  Cashiering  System  and  shall  be  fully  integrated  with  the 
Vendor's  RPP  component  of  the  PVPMISS.  This  feature  shall  be  available  to  the 
City  should  the  City  implement  a  fee  for  resident  permits  during  the  term  of  this 
contract. 
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(4.24.4)     Future  Enhancements 


The  Vendor  shall  accommodate  internet  communication  with  participants  in  the 
Resident  Permit  Parking  program  such  that  renewal  permits  may  be  requested  via  the 
internet.  Such  capability  shall  be  accomplished  via  a  workflow  component  in  the 
RPP  system  whereby  the  renewal  request  sent  via  the  internet  populates  a  work  queue 
in  the  Vendor's  Correspondence  Workflow  Imaging  System  which  City  staff  access. 
Indexing  may  be  accomplished  via  neighborhood  permit  number.  This  work  queue 
shall  interface  with  the  Vendor's  Resident  Permit  Parking  System  in  an  automated 
fashion  with  minimal  manual  involvement.  City  staff  would  the  process  renewal 
transactions  as  described  above. 


259 


260 


4.25 


PROVISION  OF  COMPLETE  SERVICES 
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(4.25)  PROVISION  OF  COMPLETE  SERVICES 
TO  ALL  TICKETS  ON  THE  DATABASE 


The  Vendor  shall  be  responsible  for  providing  complete  services  (as  defined  in  the 
section  of  this  RFP  entitled  "Scope  of  Services")  in  relation  to  violation  tickets  issued 
prior  to  the  effective  date  of  the  contract  entered  into  pursuant  to  the  RFP  (i.e.,  pre- 
contract tickets).  All  services,  functions  and  system  elements  provided  to  current 
tickets  (those  tickets  submitted  for  processing  on  or  after  the  date  of  contract)  must  be 
provided  to  pre-contract  tickets. 


Some  examples  of  the  required  services,  functions  and  system  elements  are: 


-  processing  payments  and  other  dispositions, 

-  providing  complete  on-line  access  to  ticket  disposition  information,  unless 

otherwise  specified  by  the  City, 

-  providing  all  required  services,  such  as  notices  and  non-renewal  processing. 


The  provision  for  complete  services  for  pre-contract  tickets  is  an  inalienable 
responsibility  of  the  Vendor.  THE  CITY  WILL  PROVIDE  NO  REIMBURSEMENT 
FOR  SERVICES  DELIVERED  ON  THESE  OLDER  TICKETS  OTHER  THAN 
APPLICABLE  PAYMENTS  FOR  THE  SMALL  NUMBER  OF  THESE  TICKETS 
SUBJECT  TO  THE  TERMS  AND  CONDITIONS  APPLICABLE  FOR  SECONDARY 
COLLECTIONS. 
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(4.26)  SYSTEM  DOCUMENTATION  AND  USER  REQUIREMENTS 


Quality  documentation  is  considered  an  essential  part  of  the  provision  of  turnkey 
systems  and  services  for  this  RFP  and  system  development  or  modification  tasks. 

The  Vendor  shall  provide  documentation,  at  a  minimum,  for  all  violation  processing 
activities  for  which  the  Vendor  is  responsible  including  the  following  areas: 

-  user  manuals,  which  will  describe  in  detail  the  step-by-step  functioning  of  the 
system  from  the  user's  perspective. 

-  programmer  documentation,  which  will  contain  program  narrative,  functional 
specifications,  all  related  criteria,  flowcharts,  listings,  input  examples,  file 
descriptions,  and  so  on; 

-  the  manner  in  which  all  processing  functions  are  carried  out; 

-  the  interrelationships  or  interfaces  between  the  various  subsystems  or  elements; 

-  the  locations  at  which  such  functions  are  carried  out; 

-  the  timing  for  the  carrying  out  of  each  function;  and 

-  managerial  summaries,  which  will  provide  managers  with  an  understanding  of 
the  role  of  the  system. 


The  Vendor  shall  document  all  enhancements  or  modifications  to  the  systems  and 
procedures  and  furnish  the  City  with  such  documentation  within  thirty  (30)  days  of  the 
implementation  of  such  modifications. 
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(4.27)  PERFORMANCE  REPORTING 


The  requirement  for  comprehensive  performance  reporting  has  been  detailed  elsewhere 
in  this  RFP.  However,  the  outline  contained  herein  shall  serve  to  reiterate  this 
requirement  and  to  state  this  as  a  requirement  for  sections  of  this  RFP  where  it  has  not 
been  stated. 

The  Vendor  shall  implement  and  operate  a  system  for  recording,  monitoring  and 
responding  to  all  complaints  and  requests  by  the  City  relative  to  the  Vendor's 
performance  and  obligations  pursuant  to  the  agreement. 

The  Vendor  shall  develop  procedures  and  reporting  formats  to  track  and  respond  to  all 
requests  and  complaints  in  a  systematic  and  timely  manner. 

The  Vendor  shall,  for  each  request  or  complaint,  prepare  a  managerial  summary, 
implementation  plan,  comprehensive  project  analysis  and  /or  other  documents  as 
required  by  the  City. 

The  Vendor  shall  prepare  a  listing,  on  a  regular  basis  as  determined  by  the  City,  of  all 
active  requests  or  complaints,  the  status  of  each  request  or  complaint  and  the  targeted 
completion  date  of  each  request  or  complaint. 
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(4.28)  SECURITY 


The  Vendor  shall  provide  a  security  system  which  will  protect  both  physical  items  and 
any  and  all  parking  violation  ticket  data. 

The  Vendor  shall  provide  two  major  aspects  of  security: 

1)  physical  security  of  equipment,  files,  communication  network  and  other 

applicable  items;  physical  security  would  need  to  include,  but  not  be  limited  to: 

a)  controlled  entry  to  facilities; 

b)  facility  alarms;  locked  files,  guards,  or  other  devices  reasonably  expected  to 
prevent  loss  or  unauthorized  removal  of  documents; 

c)  controlled  access  to  processing  areas; 

d)  security  features  (i.e.  cameras)  at  facilities; 

e)  extensive  audit  and  control  procedures; 

f)  fire  protection,  protection  against  smoke  and  water  damage;  and 


2)  logical  and  data  security  designed  into  the  system  itself  to  safeguard 
confidentiality  and  prevent  system  abuse.  The  system  should  provide  a 
comprehensive  and  user-oriented  security  system  to  restrict  access  to  only 
authorized  users.  In  addition,  the  system  should  provide  the  following: 

a)  accommodation  of  a  variety  of  clearance  levels,  i.e.,  some  users  will  need  to 
update  data  while  for  others  'read  only'  will  suffice;  limitations  on  access 

based  on  proper  authorization  and/or  terminal; 

b)  passwords,  access  logs,  badges  or  other  methods  reasonably  expected  to 
prevent  loss  or  unauthorized  access  to  electronically  or  manually  held  data; 
passwords,  access  logs,  badges  or  other  manually  held  data; 

c)  unique  user  access  identification  that  must  be  changed  at  periodic  intervals; 

d)  back-up  records  for  update  transactions; 

e)  audit  trails,  audit  reports,  and  full  accountability  for  all  transactions; 

f)  detailed  transaction  histories  with  date,  time,  and  identification  of 
transactions; 

g)  strict  control  and  reconciliation  procedures  for  system  updates; 

h)  control  of  dial-up  access  to  the  system; 

i)  virus  detection  and  control. 

In  addition  to  steps  the  Vendor  may  take  to  secure  the  system,  the  Vendor  shall  comply 
with  reasonable  security  measures  submitted  by  the  City.  Failure  of  the  City  to  provide 
a  partial  or  complete  security  plan  shall  not  be  construed  as  relieving  the  Vendor  of 
security  responsibilities. 
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(4.29)  COMPLETE  AND  COMPREHENSIVE  BACK-UP 
OF  ALL  SYSTEMS  AND  FILES 
AND 

ALTERNATIVE  PROCESSING  ARRANGEMENTS 


The  Vendor  shall  provide  complete  back-up  systems  and  capacity  for  all  on-line 
systems  including  hardware,  software,  communication  lines  and  other  equipment. 

The  Vendor  shall  retain  sufficient  back-up  files  so  that  reconstruction  of  all  processing 
activities  can  be  accomplished  for  audit  purposes  and  emergency  situations. 

The  Vendor  shall  provide  for  the  duplication  of  all  programs  and  files  and  those 
programs  and  files  subsequent  movement  offsite  from  their  data  processing  facility  to 
ensure  copies  are  available  in  the  event  the  originals  are  destroyed. 

The  Vendor  shall  provide  for  alternate  processing  arrangements/locations  to  ensure  that 
processing  could  continue  in  the  event  of  damage  or  destruction  to  the  Vendor's  data 
processing  facility(ies).  Detailed  plans  shall  exist  to  provide  for  an  orderly  move  to  the 
alternative  site.  Test  processing  shall  be  completed  periodically  at  the  recovery  site  to 
ensure  continued  equipment  compatibility,  to  train  employees  and  to  identify 
weaknesses  in  the  contingency  plan.  Testing  shall  be  comprehensive  and  shall 
approximate  actual  processing  requirements. 

The  Vendor  is  responsible  for  performing  periodic  reviews  and  tests  to  ensure  identified 
and  approved  procedures  and  functions  perform  in  accordance  with  expectations  and 
plans. 
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(4.30)  TRAINING 


The  Vendor  shall,  at  the  City's  request,  and  at  no  cost  to  the  City,  conduct  instruction 
and  training  of  City  personnel  in  connection  with  any  of  the  services,  including  but  not 
limited  to,  system  enhancements  and  subsystems,  for  which  the  Vendor  is  responsible 
hereunder. 

Some  EXAMPLES  of  training  are: 
Boot  and  Tow  Operations 

-  use  of  on-line  system; 

-  instructions  on  the  use  of  on-line  updating  functions; 

-  provision  of  a  tow  and  hold  manual,  etc. 

-  use  of  mobile  telecommunications  devices  /  hand-held  devices  and  system, 
including  file  upload  /  download  and  reporting. 

On-Line  Cashiering 

-  instruction  in  how  to  access  and  use  relevant  software; 

-  use  of  on-line  system; 

-  how  to  post  payments; 

-  how  to  access  totaling  programs; 

-  instruction  in  end  of  day  data  reconciliation; 

-  routine  maintenance; 

-  paper  changing. 

On-Line  Inquiry  System 

-  How  to  cross  reference  with  microfiche; 

-  how  to  produce  hard  copy  documents. 

Imaging  /  Correspondence  Workflow  System 

-  instructions  on  the  use  and  operation  of  scanner; 

-  instructions  on  the  processing  of  correspondence  via  workflow  application; 

-  instructions  on  the  processing  of  hearings  via  workflow  application. 

In  addition,  seminars  will  be  developed  by  the  Vendor  as  requested  by  the  City. 
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(4.31)  CAPACITY  AND  VOLUMES 


Note:  Volumes  are  also  provided  in  other  sections  of  this  RFP  as  they  relate  to  various 
activities. 


(4.31.0)  On-Line  Active  Database 

As  of  June  30,  2006,  the  active  on-line  database  contains  approximately  2,400,000 
tickets  and  approximately  1,000,000  license  plates.  ("Active  on-line  database"  refers  to 
violations  fully  paid/dismissed  and  non-archived,  and  violations  fully  unpaid,  partially 
paid,  overpaid,  on  hold,  etc.) 

The  active  on-line  database  has  contained  as  much  as  approximately  12,000,000 
violations.  While  the  City's  PVPMISS  activities  should  serve  to  minimize  the  net 
increase  of  active  database  violations,  under  certain  circumstances  the  City  can  envision 
the  need  to  eventually  match  or  exceed  the  former  12  million  violation  capacity 
requirements. 


(4.31.1)  Archive  Violations 

As  of  June  30,  2006,  approximately  29,000,000  violations  are  in  a  category  defined  in 
this  RFP  as  archived.  The  Vendor  should  anticipate  the  archive  category  to  increase 
substantially  during  the  course  of  the  agreement.  Of  the  total  approximately  29,000,000 
archived  violations,  approximately  8,000,000  violations  are  available  on  microfilm; 
approximately  29,000,000  violations  (archived  February,  1997  to  June,  2006)  are 
available  via  the  City's  Ticket  Archive  System.  Please  see  section  4.23  of  this  RFP, 
"File  Archive"  for  PVPMISS  archive  requirements. 


(4.31.2)  Ongoing  Violation  Ticket  Volumes 

The  Vendor  shall  provide  the  capacity  to  process,  as  specified  herein,  between  35,000 
and  50,000  tickets  per  week.  Yearly  ticket  issuance  has  approximated  between  1.5  and 
1.9  million  violations  within  each  of  the  past  five  (fiscal)  year  periods. 


(4.31.3)  Payment  Volumes 

The  Vendor  must  have  sufficient  capacity  to  process  payments  in  volume  of  up  to 
70,000  violations  per  week,  or  as  much  as  approximately  50,000  payment  documents. 
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(4.31.4)  Other  Volumes 

The  following  approximate  workload  tracking  statistics  (for  the  period  July  \,  2008 
through  June  30,  2009)  are  provided  to  illustrate  the  scope  of  the  City's  PVPMISS 


related  activities. 

New  Tickets  Received  1,591,832 

#  Tickets  Noticed  907,113 

#  Plates  Noticed  638,104 

#  Notices  Mailed  653,947 
Vehicles  Booted  6,534 

#  Violation  Tows  13,755 
Counter  Activity  22,139 
Phone  Activity  419,016 
General  Corr.  Received  90,348 
Leased  Vehicle  Corr.  3,191 
Registry  Releases  30,837 

#  Hearings  Held  13,036 
Total  #  Dismissals  65,648 
Resident  Permits  Issued  57,873 

#  Lockbox  Payments  Processed  556,219 

#  Pay  by  Phone  Payment  Processed  37,492 

#  Internet  Payment  Processed  344,240 

#  MA  RMV  Name  &  Address: 

Requests  775,443 

Re-Requests  91,799 

#  MA  RMV  Non-Renewal  Requests: 

Mark  Requests  202,068 

Clear  Requests  129,098 
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(4.32)  TEST  SYSTEM 


The  Vendor  shall  be  advised  that  the  City  operates  under  the  premise  that  changes  or 
new  developments  inherently  present  unexpected  results  or  problems.  All  system 
modifications,  enhancements,  or  other  changes  shall  be  properly  tested  by  the  Vendor 
and  shall  be  approved  by  the  City  before  their  implementation. 

The  Vendor  shall  provide  comprehensive,  efficient  and  effective  test  files/test  system  to 
test  both  batch  and  on-line  systems  and  shall  provide  the  City  with  actual  test  results 
before  implementing  any  significant  system  changes. 

Testing  shall  occur  at  various  levels  of  system  development. 

The  City  requires  a  comprehensive  and  functional  system  test  plan  for  any  and  all 
untested  applications  or  applications  that  have  not  been  operating  and  debugged  in  an 
actual  Boston  production  environment.  The  objectives  of  the  Systems  Testing  are  to 
identify  test  conditions  and  prepare  all  automated  and  manual  procedures  for  system 
test;  and  to  confirm  that  the  Vendor  and  its  systems  performed  all  the  functions  that  are 
required  in  the  Scope  of  Service  section  of  this  RFP,  their  proposal  or  any  other 
documentation  submitted  by  the  Vendor. 

Vendor's  Responsibilities: 

The  Vendor  shall  develop  a  System  Test  Plan  and  submit  the  plan  to  the  City  for 
approval.  Testing  activities  must  address  all  aspects  of  the  Vendor's  responsibilities 
and  functions  of  the  system,  including  terminal,  communications,  software,  operating 
procedures,  user  procedures  and  other  documentation.  Procedures  should  be  included 
in  the  plan  to  verify  and  certify  the  functions  and  quality  of  the  PVPMISS  and  to  ensure 
that  the  system  performs  according  to  the  specifications. 

Specific  Vendor  Responsibilities  Include: 

Develop  a  test  matrix  to  include  transactions,  conditions,  and  desired  results 
Develop  test  data  files 

Perform  and  document  unit  tests  and  submit  to  the  City  for  approval 
Debug  each  program 

Conduct  system  test  involving  all  functions  and  interfaces 
Document  the  final  system  test  and  submit  to  the  City  for  approval 

The  City's  Responsibilities  During  the  System  Testing  Phase: 

Review  and  approve  the  test  plan  including  the  development  of  the  test  matrix 
and  corresponding  test  files 

Review  and  approve  if  necessary  each  unit's  test  results 
Provide  written  approval  of  the  test  results  for  the  total  system 

System  Testing  Phase  Milestones: 

City  approval  of  the  test  plan 

Accurate  processing  of  complete  test  data  package 

City  approval  of  the  system  test 
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(4.33)  RECOVERY  FROM  CATASTROPHIC  FAILURE 


Recovery  from  catastrophic  failure  is  defined  as  those  corrective  efforts  undertaken  at 
the  computer  site  as  a  direct  result  of  a  natural  disaster  (e.g.,  fire  or  flood)  or  other 
catastrophe  which  has  caused  either  disruption  of  services  to  the  City  for  extended 
periods  of  time  or  loss  of  data. 

The  Vendor  shall  reimburse  the  City  an  amount  equal  to  the  cost  incurred  by  the  City  to 
re-enter  any  data  should  the  Vendor  fail  to  restore  said  data,  and  any  other  costs 
incurred  or  experienced  by  the  City  because  of  the  interruption  of  services  and/or  the 
failure  to  restore  lost  data. 

It  will  be  the  responsibility  of  the  Vendor  to  take  every  precaution  to  ensure  that  all 
systems,  files,  data,  equipment,  communications,  and  facilities  are  reliable.  In  the  event 
that  a  natural  disaster  does  disrupt  the  system,  the  Vendor  must  have  a  detailed,  City 
approved  recovery  plan  in  place,  tested  and  ready  to  be  implemented  for  all  key 
facilities  so  that  services  are  restored  quickly  and  in  accordance  with  City  performance 
standards. 

The  Vendor  must  thoroughly  explain  its  disaster  recovery  and  back-up  plan,  which  at  a 
minimum  should  address  the  following: 

1)  procedures  for  back-up  of  all  software  and  computer  programs,  files,  computerized 
procedures,  etc.; 

2)  off-site  duplication  of  all  software  and  computer  programs,  files,  computerized 
procedures,  etc.; 

3)  repair  procedures  for  all  hardware,  communications,  and  other  equipment  in  order  to 
minimize  the  time  required  to  restore  service; 

4)  alternate  processing  arrangements  in  the  event  of  severe  damage  to  facilities;  and, 

5)  proposed  periodic  and  comprehensive  testing  of  emergency  procedures. 
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(4.34)  ORGANIZATION.  PLAN  OF  SERVICES  AND  PERSONNEL 


(4.34.0)  Note 

While  this  section  of  the  RFP  provides  information  and  discussions  pertaining  to  the 
crucial  areas  of  Vendor  organization  and  plan  of  services,  it  should  be  noted  that 
additional  information  and  discussions  are  provided  elsewhere  in  this  RFP  as  they  relate 
to  a  particular  function(s).  To  the  extent  that  a  Proposer's  response  to  this  section  of  the 
RFP  overlaps  with  information  furnished  elsewhere  in  its  proposal,  the  Proposer  is 
encouraged  to  repeat  its  discussion  of  any  such  item. 


(4.34.1)  Single  Point  of  Responsibility 

Two  or  more  proposers  may  combine  to  submit  a  response  to  this  RFP.  However,  one 
company  must  be  designated  as  the  Primary,  and  single  point  of  responsibility.  Vendor 
with  overall  responsibilities.  This  company  must  have  experience  preferably  with 
PVPMISS'  that  are  similar  and  comparable  to  Boston's  PVPMISS.  Subcontractors  may 
be  used  but  the  prime  contractor,  i.e.,  Prime  Vendor,  must  accept  full  responsibility  for 
any  subcontractor's  performance  and  bear  direct  overall  responsibility  for  services, 
oversight  and  management  to  the  City. 

All  subcontractors  must  be  identified  and  listed.  It  is  expected  that  proposers  will 
identify  and  discuss  all  subcontractors  (if  any)  specific  to  any  function,  service,  etc., 
within  the  specific  section(s)  of  the  RFP  that  address(es)  said  specific  function,  service, 
etc.  In  addition,  for  the  purposes  of  this  section  of  the  RFP,  proposers  are  expected  to 
provide  a  comprehensive  listing  of  all  subcontractors  (if  any)  and  a  summation  of  their 
responsibilities.  Also,  the  Prime  Vendor  must  describe  the  type  of  contractual  and 
price  arrangements  that  will  exist  with  all  subcontractors.  Changing  subcontractors 
during  the  contract  period  will  be  allowed  with  the  prior  approval  of  the  City. 

The  City  values  the  single  point  responsibility  for  the  PVPMISS  in  light  of  a  number  of 
factors  including,  but  not  limited  to,  the  demand  for  system,  operational  and  data 
accuracy,  credibility  and  integrity;  the  critical  need  to  be  responsive  to  the  public;  the 
sensitive  nature  of  parking  enforcement,  adjudication  and  collection  activities  relative  to 
the  public;  the  complex  and  difficult  nature  of  the  issuance  and  processing  functions 
and  activities  associated  with  the  parking  ticket;  the  scope,  size  and  complexity  of  the 
PVPMISS;  the  critical  need  for  quality  control;  and  the  continual  need  to  revise  and 
enhance  the  PVPMISS  through  ongoing  changes. 

With  one  company  as  the  Prime  Vendor,  the  City  and  the  Prime  Vendor  will  be  in  a 
better  position  to  demand  and  receive  close  oversight  and  extensive  quality  control  of 
all  PVPMISS  and  PVPMISS  related  activities  as  well  as  a  primary  on-call  liaison  or 
project  manager  to  coordinate  and  respond  to  PVPMISS-wide  issues  and  problems  and 
to  make  significant  contributions  to  the  efficiency,  effectiveness,  integrity  and 
credibility  of  the  PVPMISS. 
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While  it  is  not  the  intent  of  the  City  to  limit  in  a  very  restrictive  manner  the  number  of 
organizations  and  business  entities  that  join  together  in  submitting  a  proposal  and/or 
performing  work  required  by  this  RFP,  the  City  is  concerned  about  potential 
management,  responsibility/liability  and  other  programmatic  and  financial  issues  that 
could  arise  from  a  large  number  of  organizations  and  business  entities  joining  together 
and/or  the  absence  of  a  major  organization  or  business  entity  with  responsibility  for  the 
primary  duties  and  responsibilities  for  significant  functions  and  requirements  of  this 
RFP. 

Thus,  at  a  minimum,  the  Prime  Vendor  should  be  the  organization  and/or  business 
entity  that  is  providing  the  primary  PVPMISS  software  and  computer  systems.  It  is 
preferable  that  the  Prime  Vendor  perform  other  major  functions,  activities  and  services 
required  under  this  RFP. 


(4.34.2)  Highly  Effective  Full  Service  PVPMISS  Organization  Including 
Management  and  Oversight 

The  Vendor  is  required  to  provide  an  organization  and  plan  of  services  that  at  a 
minimum  will  sufficiently  satisfy  all  RFP  requirements  including  the  provision  of 
comprehensive  and  integrated  management  and  the  efficient  and  effective  oversight  and 
delivery  of  all  Vendor  responsibilities  under  the  RFP.  This  includes,  but  is  not  limited 
to,  internal  Vendor  operations,  personnel  and  facilities;  and  external  operations, 
activities  and  relationships  (i.e.,  with  Motor  Vehicle  Departments,  various  BTD 
divisions,  credit  card  processing  organizations). 

As  previously  discussed  in  this  RFP,  the  Vendor  shall  be  required  to  maintain  a  Boston 
Office  within  close  proximity  to  Boston  City  Hall,  which  is  located  in  downtown 
Boston  at  Government  Center.  Also,  as  previously  discussed,  unless  compelling 
arguments  are  presented  to  the  contrary,  the  City  desires  that  as  many  Boston-based 
responsibilities  (in  terms  of  geography)  as  feasible  be  performed  at  the  Vendor's  Boston 
Office.  Further,  the  City  desires  that  the  number  of  overall  worksites  be  minimized. 

The  City  desires  that  the  Vendor's  Boston  and  Data  Center/  'Head  Office'  organizations 
are  structured  to  optimally  manage  and  complete  the  scope  of  the  RFP  in  terms  of: 
effective  and  efficient  primary  responsibility  and  overall  practicable  control,  the 
effective  and  efficient  overall  integration  and  quality  control  of  PVPMISS  functions, 
clearly  defined  lines  of  authority,  location  and  arrangement  of  facilities, 
comprehensiveness  and  quality  of  internal  operations  and  major  functional  areas,  the 
ability  to  adapt  readily  to  changes,  a  closely  knit  and  flexible  organization,  and  effective 
relationships  with  subcontractors  (if  any). 

The  organization  structures,  relationships,  staffing  patterns,  etc.,  must  be  clearly  and 
comprehensively  presented  in  charts,  written  text,  and/or  through  other  means  of 
presentation.  The  numbers,  types,  locations  of  staff  and  offices  for  all  types  of 
functions  and  activities  should  be  clearly  discernible. 
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(4.34.3)  Key  Personnel 


The  Vendor  will  commit,  identify  and  provide  at  a  minimum  a  sufficient  number  of 
diversely  qualified  key  PVPMISS  personnel  that  would  be  required  to  efficiently, 
effectively  and  in  a  timely  manner  provide  and  operate  Boston's  PVPMISS  at  very  high 
performance  and  quality  levels  with  no  or  minimum  risk,  exposure  and/or  disruption  to 
the  City's  current  levels  of  PVPMISS  operations  and  revenue. 
The  City  demands  experienced,  senior  personnel  for  areas  of  major  responsibility 
throughout  the  contractual  period.  The  Vendor  is  expected  to  provide  key  personnel 
who  possess  a  high  level  of  actual  and  direct  PVPMISS  experience  and  performance  in 
PVPMISS  operating  environments  comparable  and  similar  to  Boston's  in  terms  of 
volumes  and  types  of  transactions  and  other  RFP  requirements.  The  Vendor  is  also 
required  to  provide  a  high  level  of  assurance  that  key  personnel  possess  the  high  level 
of  skills,  abilities,  knowledge  and  expertise  required  by  a  complex,  unique,  hybrid  and 
specialized  PVPMISS. 

The  number,  type  and  level  of  key  personnel  that  need  to  be  assigned  to  the  Boston 
PVPMISS  is  to  an  extent  a  function  of  a  number  of  factors  and  variables  including,  but 
not  limited  to: 

the  flexibility  of  the  PVPMISS  and  ease  and  reliability  of  modification 

the  number,  type,  quality,  complexity,  maturity,  and  demonstrated  effectiveness 
of  turnkey  systems,  components,  features,  etc.,  required  by  this  RFP 

the  extent  that  the  turnkey  systems,  components,  features,  etc.,  required  by  this 
RFP  have  been  tested  in  a  comparable  and  similar  production  environment  with 
comparable  and  similar  transactions 

the  nature  and  amount  of  design  and  development  that  needs  to  be  done 

the  number  and  type  of  performance  levels  and  problems  being  encountered,  and 

the  number,  type,  quality,  competency  and  experience  of  personnel  assigned. 

Key  personnel  may  be  located  in  Boston  or  at  processing  sites  such  as  a  datacenter 
which  may  be  situated  outside  the  City.  However,  it  should  be  clearly  understood  that 
the  City  prefers  to  have  as  many  key  personnel  located  at  worksites,  the  fewer  the 
better,  as  close  by  as  possible  to  City  Hall. 

Key  personnel  would  include  project  and  program  management,  management, 
administrative,  systems  analyst,  business  analyst,  programmer,  network  administration, 
quality  control  specialist,  operational,  production  and  other  staff  who  actually  have 
responsibility  in  specific  or  general  areas  of  importance  to  providing,  operating  and 
enhancing  Boston's  PVPMISS. 
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Whether  or  not  the  Vendor's  main  data  processing  facility  is  located  within  or  outside  of 
the  downtown  Boston  area,  certain  key  personnel  including,  at  a  minimum,  a  senior 
official  from  the  Primary  Vendor,  a  local  project  manager,  at  least  one  (1)  senior 
business/systems  analysts,  at  least  two  (2)  business  systems  analysts  with  expertise  and 
experience  in  network  management  and  the  applicable  LANS  and  WANS  and  expertise 
and  experience  in  programming  and  systems  support  for  microcomputer  applications, 
and  at  least  one  (1)  manager  with  expertise  in  hardware  installation  and  maintenance 
must  be  immediately  available  (within  a  30  minute  time  period),  on  an  every  workday, 
any  time  of  day,  routine  basis,  to  meet  with  BTD/OPC  staff  located  at  Boston  City  Hall 
in  downtown  Boston. 

Whether  or  not  a  Vendor's  facilities  for  lockbox,  noticing,  data  entry  and  any  other 
major  activities  are  or  are  not  located  in  the  downtown  Boston  area,  key  personnel 
responsible  for  these  functions  must  be  immediately  available,  within  a  30  minute  time 
period,  on  an  every  workday,  any  time  of  day,  routine  basis,  to  confer  with  City  staff 
and  must  be  available  within  a  24  hour  time  period,  on  an  every  workday,  routine  basis, 
to  meet  with  City  staff  located  at  Boston  City  Hall  (or  with  City  staff  located  at  the  Tow 
Lot  located  just  outside  downtown  Boston).  The  Prime  Vendor  must  receive  the  City's 
approval  to  designate  individuals  as  key  personnel  for  these  other  responsibilities  where 
the  designated  individual  does  not  have  a  direct,  actual  work  assignment  relative  to  the 
specific  activity.  The  City  may  (depending  upon  organization  and  performance  issues 
including  that  of  key  personnel)  require  at  its  sole  discretion  the  assignment  and 
availability  of  additional  key  personnel  in  a  manner  described  above.  It  is  not  the  intent 
to  delineate  for  all  situations  and  circumstances,  the  assignment  of  local  staff  from  the 
Vendor.  However,  by  way  of  illustration,  the  lockbox,  noticing,  and  data  entry 
functions  are  major  functions  where  key  personnel  will  be  required  to  interface  with 
City  staff  and  must  be  available  in  the  manner  described  above. 


(4.34.4)  On-Site  Assistance 

The  Vendor  shall  at  all  times  assign  an  individual  designated  as  a  key  personnel  to  be 
available  in  City  Hall  on  an  as-directed  basis  during  periods  of  development,  problems, 
or  situations  involving  corrective  action.  This  individual  shall  have  a  proficient 
knowledge  of  all  ticket  processing  activities  for  which  the  Vendor  is  responsible  and 
have  at  least  two  years  direct  PVPMISS  programming  and/or  systems  analysis 
experience  similar  and  comparable  to  Boston's  PVPMISS.  This  individual  may  be  one 
of  the  key  personnel  identified  above. 
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(4.34.5)  Programmer  Analysts 


The  Vendor  shall  provide  a  minimum  of  one  (1)  experienced  project 
programmer/analyst,  who  shall  be  responsible,  on  a  full  time  basis,  for  programming 
new  or  additional  management  reports,  new  applications  and  other  system 
enhancements  and  modifications  requested  by  the  City.  This  programmer/analysts,  as  a 
member  of  the  Vendor's  key  personnel  team,  shall  be  in  addition  to 
programmer/analyst  computer  personnel  assigned  to  the  Boston  system  or  central  Data 
Center  support  operations.  The  City  shall  have  the  prerogative  to  establish  priority 
among  outstanding  programming  projects.  The  Vendor  will  provide,  at  the  City's 
request,  a  weekly  account  or  schedule  of  all  past  and  planned  programming  activities  of 
the  programmer/analyst. 

It  should  be  clearly  understood  that  this  programmer/analyst  is  over  and  above  the  staff 
that  are  needed  to  provide  and  maintain  the  turnkey  systems  at  performance  levels 
which  are  not  below  the  performance  levels  in  existence  prior  to  July  1,  2010,  below  the 
performance  levels  required  by  this  RFP  on  July  1,  2010,  and/or  below  the  performance 
levels  prior  to  any  previous  quarterly  performance  levels  during  the  term  of  the  contract. 
This  means  that  the  Vendor  will  be  required  to  maintain  and  support  new  activities  on 
an  on-going  basis.  If  additional  staffing  is  required,  the  Vendor  must  provide  the 
necessary  resources  (at  no  cost  to  the  City). 


(4.34.5.1)  Assignment  of  a  Network  Administrator  and  Micro-Programmer 

It  is  the  intent  and  preference  of  the  City  to  have  the  Vendor  assign,  as  a  member  of  the 
Vendor's  key  personnel  team,  a  primary  (single)  individual  to  perform  many  of  the 
network  administration  functions  at  the  OPC  City  Hall  office  and  various 
microcomputer  activities.  The  service  needs  and  requirements  of  the  City  require  a 
working  arrangement  of  approximately  5  days  per  week  and  thirty-five  (35)  hours  per 
week  from  a  single  person. 

Overview  of  Service  Requirements 

The  City  requires  an  individual  to  provide  professional  network,  microcomputer 
analysis,  user  liaison,  programming,  technical  assistance,  maintenance  and  support 
services.  This  individual  will  also  coordinate  other  Vendor  staff  relative  to  assistance 
for  City  oriented  PVPMISS  network  and  microcomputer  related  activities  and  will  also 
play  a  key  role  in  integrating  systems  and  applications.  This  individual  will  further 
assist  City  staff  and  provide  technical  liaison  support  relative  to  the  services  described 
herein  as  well  as  for  various  other  microcomputer  and  networking  activities.  In 
addition  to  responding  to  City  requests  and  assignments,  the  individual  assigned  by  the 
Vendor  to  perform  the  microcomputer  related  activities  must  be  self-directed  and 
possess  sufficient  initiative  to  analyze  and  determine  system  and  application 
modification,  development,  documentation,  training  and  support  requirements. 
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The  individual  will  likely  be  assigned  a  primary  workspace  at  the  Office  of  the  Parking 
Clerk,  Room  224,  BOSTON  CITY  HALL.  The  individual's  primary  workspace  may,  at 
the  City's  discretion  be  relocated  to  another  worksite  within  the  BTD  organization.  It  is 
expected  that  the  individual  assigned  by  the  Vendor  will  also  have  microcomputer 
resources  available  at  his/her  disposal,  independent  of  City  resources.  The  individual, 
on  occasion,  may  be  allowed  to  conduct  work  off-site  from  the  above  location(s)  in  the 
event  that  it  will  provide  for  the  expeditious,  effective  and  efficient  completion  of  a  task 
or  set  of  tasks.  However,  if  the  Vendor  believes  that  certain  functions  and  assignments 
could  be  better  performed  by  other  Vendor  staff,  the  City  may  be  willing  to  reduce  the 
number  of  work  hours  of  the  primary  individual. 

All  computer  software,  programs  and  procedures  relating  to  distinct  and  stand-alone 
City  applications  (i.e.,  Traffic  Management  Permitting  System)  that  are  maintained  by 
this  individual  as  they  relate  to  the  services  to  be  performed  under  this  section  of  the 
RFP  shall  remain  the  property  of  the  City. 


(4.34.5.2)  Assignment  of  Interactive  Voice  Response  System  (IVRS)  Analyses) 

The  Vendor,  as  part  of  its  key  personnel  team,  is  required  to  provide  for  the  duration  of 
the  contract  a  senior  Interactive  Voice  Response  System  (IVRS)  technical  developer 
support  person  with  relevant  IVRS  experience  and  interface  experience  with  mainframe 
or  other  applicable  core  systems  used  for  the  PVPMISS.  This  person  should  also 
possess  development  experience  in  the  quoted  system's  operating  and  software 
environment.  Additionally,  this  person  should  have  experience  interfacing  with  the 
core  PVPMISS  mainframe  or  other  system.  This  person  should  possess  proficiency  in 
Speech  Recognition  technology  relative  to  future  IVRS  initiatives  described  in  Section 
4.17,  Automated  Interactive  Voice  Response  System,  of  this  RFP. 

The  person  must  be  available  to  be  on-site  for  installation,  testing,  debugging  and 
acceptance  of  the  new  application,  major  changes,  and  on  an  immediate  on-call  basis  at 
the  request  of  BTD/OPC.  This  IVRS  analyst  will  also  be  the  designated  liaison  to  other 
Vendor  staff,  BTD/OPC  staff,  MIS  staff,  City  Telecommunication  staff,  City  Telephone 
System  Vendor  Staff,  and  Executone  staff  involved  with  their  Automatic  Call 
Distributor  (ACD). 

In  addition  to  the  senior  IVRS  analyst,  the  Vendor,  at  a  minimum,  will  provide  for  the 
duration  of  the  contract,  a  technical  systems  analyst  or  micro-programmer  or  equivalent 
back-up  with  experience  in  IVRS  to  assist  the  senior  technical  IVRS  person  and  act  as  a 
secondary  liaison.  This  analyst  or  micro-programmer  may  also  be  expected  to  be  on- 
site  for  installation,  testing,  debugging  during  acceptance  and  on  a  routine  basis  if 
required  by  the  City. 

Please  note  that  the  IVRS  application  is  critical  application  relative  to  delivery  of 
customer  service  and  BTD/OPC 's  image  with  the  public  and  its  customers. 


(4.34.5.3)  Assignment  of  WWW  /  Internet  Applications  Analyst 

The  Vendor,  as  part  of  its  key  personnel  team,  is  required  to  provide  for  the  duration  of 
the  contract  a  senior  WWW  /  Internet  Applications  technical  developer  support  person 
with  relevant  WWW  /  Internet  Applications  experience  and  interface  experience  with 
mainframe  and  other  applicable  core  systems,  including  financial  systems,  used  for  the 
PVPMISS.  This  person  should  also  possess  development  experience  in  the  quoted 
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system's  operating  and  software  environment.  Additionally,  this  person  should  have 
experience  interfacing  with  the  core  PVPMISS  mainframe  or  other  system. 

This  person  must  be  available  to  be  on-site  for  designing,  testing,  installation, 
debugging  and  acceptance  of  web-based  applications  as  needed  and  on  an  immediate 
on-call  basis  at  the  request  of  BTD/OPC  staff. 

In  addition  to  the  senior  WWW  /  Internet  Applications  Analyst,  the  Vendor,  at  a 
minimum,  will  provide  for  the  duration  of  the  contract,  a  technical  systems  or  network 
analyst  or  micro-programmer  with  experience  in  web-based  applications  to  assist  the 
senior  technical  WWW  /  Internet  Applications  Analyst  and  act  as  a  secondary  liaison. 
This  analyst  or  micro-programmer  may  also  be  expected  to  be  on-site  for  installation, 
testing,  debugging  during  acceptance  testing  and  on  a  routine  basis  if  required  by  the 
City. 

Please  note  that  the  Pay-By- Web  and  future  web-based  applications  are  critical  relative 
to  the  delivery  of  customer  service  and  BTD/OPC 's  image  with  the  public  and  its 
customers. 


(4.34.6)  Consultant  Services 

The  Vendor  must  provide  Consultant  Services  for  various  traffic  and  parking  operations 
and  management.  This  service  may  provided  via  in-house  or  subcontracted  services  at 
the  Vendor's  cost. 

(4.34.6.1)  Consultant  Services  for  Enforcement  Activities 

The  City  anticipates  a  continuing  need  for  provision  of  these  services  in  the  specific 
area  of  parking  ticket  issuance  and  enforcement.  Such  consultant  services  would 
require  regular  meetings  with  BTD/Enforcement  Division  managers  and  key  staff.  At  a 
minimum,  the  services  would  include  assistance  in  the  development  of  training 
activities  of  parking  ticket  writers,  possibly  the  actual  training  of  personnel  and 
supervisors,  monitoring  ticket  issuance  and  factors  impacting  issuance,  analysis  and 
development  of  issuance  routes,  and  analysis  of  productivity.  The  Vendor  is  required  to 
identify  senior  staff  that  would  be  located  in  Boston  or  made  available  on  an  as  need 
basis. 

(4.34.6.2)  Consultant  Services  in  Traffic  and  Parking  Management 

The  Vendor  is  expected  to  provide  the  City  with  a  variety  of  services  relative  to  Traffic 
and  Parking  Management  ranging  from  information  on  new  approaches  and  systems  to 
actual  studies  and  analysis  of  BTD  operations. 

By  way  of  illustration  of  new  approaches  and  systems,  the  BTD  expects  to  be  provided 
information  on  hand-held  ticket  writers,  red-light  running  programs,  new  innovations 
relative  to  on-street  parking  such  as  in-car  meters,  and  new  applications  developed  for 
boot  and  tow  operations. 
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(4.34.7)  Routine  Programmatic  Meetings 


As  noted,  the  City  strongly  desires  for  programmatic  reasons  the  ability  to  have 
immediate  and  ongoing  access  to  key  personnel.  The  City  requires  that  key  personnel 
involved  with  any  major  functions,  activities,  services  or  responsibilities  be  made 
available  for  access  in  the  manner  described  above  and  in  addition,  be  available,  as  the 
need  arises  due  to  programmatic  issues,  to  attend  daily,  weekly  and/or  monthly  in- 
person  meetings  throughout  the  contract  period.  The  City  may  require,  at  its  sole 
discretion,  these  meetings. 

At  a  minimum,  once  all  RFP  turnkey  requirements  have  been  satisfied,  the  City  will 
normally  require  monthly  in-person  meetings  with  local  office  and  data  center  key 
personnel  to  review  the  status  of  the  PVPMISS  or  any  number  of  specific  activities  and 
projects. 


(4.34.8)  Commitment  of  Specific  Key  Personnel 

The  Vendor  needs  to  assure  and  provide  supporting  information  and  explanation  that 
the  specifically  committed  key  personnel  can  reasonably  be  expected  to  be  provided  in 
light  of  the  Vendor's  ongoing/planned  PVPMISS  and  other  contractual  commitments. 

The  City  clearly  expects  that  all  requirements  including  all  systems  and  operations 
unless  otherwise  specified  in  the  RFP  be  fully  and  successfully  implemented  and 
operational  effective  July  1,  2010.  The  City  at  its  sole  discretion  may  require  and  the 
Vendor  must  provide  additional  key  personnel  to  be  assigned  when  performance  levels 
are  below  the  performance  levels  in  existence  prior  to  July  1,  2010,  below  the 
performance  levels  required  by  this  RFP  on  July  1,  2010,  and/or  below  the  performance 
levels  prior  to  any  previous  quarterly  performance  levels  during  the  term  of  the  contract. 
While  it  is  the  intent  of  the  City  to  avoid  this  situation  via  the  requirements  of  the  RFP 
and  commitments  of  the  Vendor  (as  stated  in  the  RFP  submission)  to  be  able  to  satisfy 
those  requirements,  the  City  may  reluctantly  believe  that  corrective  action  could  involve 
additional  assignment  of  personnel  and/or  applicable  liquidated  damages  in  lieu  of 
termination  of  the  contract  and/or  applicable  liquidated  damages. 


(4.34.9)  Depth  of  Key  Personnel 

The  Vendor  is  expected  to  substantiate  its  depth  in  terms  of  key  personnel.  The  Vendor 
must  substantiate  its  capability  to  support  the  Boston  PVPMISS  with  other  additional 
similarly  qualified  staff  in  cases  of  staff  turnover,  temporary  unavailability  of  specified 
key  personnel,  an  increase  in  projects  or  problems,  substantial  enhancements  to  the 
depth  and  scope  of  applications,  or  failure  to  satisfy  contractual  requirements. 


(4.34.10)  Non-Key  Personnel  For  All  Vendor  Responsibilities 

The  Vendor  will  commit  and  provide  at  a  minimum  a  sufficient  number  of  diversely 
qualified  personnel  that  would  be  required  to  efficiently,  effectively  and  in  a  timely 
manner  provide  and  operate  Boston's  PVPMISS  at  very  high  performance  and  quality 
levels  with  no  or  minimum  risk,  exposure  and/or  disruption  to  the  City's  current  levels 
of  PVPMISS  operations  and  revenue  relative  to  all  Vendor  responsibilities  required 
under  this  RFP. 
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The  Vendor  must  identify  the  numbers  and  diverse  types  of  personnel  that  will  be 
assigned  to  ongoing  processing,  production  and  other  functions,  activities,  services  and 
responsibilities  required  under  this  RFP.  The  Vendor  must  indicate  staffing  patterns, 
numbers,  types  of  positions,  worksites,  etc. 


(4.34.11)  Experience  and  Demonstrated  Effectiveness  of 
Subcontractors  and  Subcontractor  Personnel 

The  experience  and  demonstrated  effectiveness  of  subcontractors  and  subcontractor 
personnel  is  important  to  the  City.  While  the  City  will  hold  the  Prime  Vendor 
responsible  for  the  provision  of  all  systems  and  services,  it  is  incumbent  upon  the  City 
to  ensure  wherever  possible  that  all  work  will  be  of  the  highest  quality,  timeliness, 
accuracy  and  completeness  and  that  public  funds  will  be  protected. 


(4.34.12)  Right  to  Refuse  Personnel 

As  set  forth  in  Paragraph  Z,  Section  VI  of  the  PVPMISS  Contract  (Agreement),  the  City 
reserves  the  right  to  refuse  any  individual(s)  in  the  Contractor's  employ  (including 
subcontractors)  if  the  City  is  not  satisfied  with  their  performance  as  it  relates  to  the 
Contract  to  be  entered  into  pursuant  to  this  RFP,  or  personality  conflicts  with  City 
personnel  hinder  the  effectiveness  of  the  Contract. 


(4.34.13)  Tow  Lot  Support 

The  Vendor  shall  provide,  as  part  of  its  key  personnel  team,  on-site  full  time  technical 
support  for  Tow  Lot  applications  at  the  City's  Tow  Lot  facility,  currently  located  at  200 
Frontage  Road,  Boston,  MA.  Such  individual  shall  be  responsible  for  all  day  to  day 
programmatic  activities  of  the  hand-held  ticket  issuance  application  and  interaction  with 
Enforcement  personnel  as  well  as  all  day  to  day  programmatic  activities  of  the  seizure 
identification  system  applications  and  interaction  with  Boot  and  Tow  personnel.  The 
work  hours  of  such  personnel  may  vary  and  shall  be  determined  by  the  operational 
needs  of  Tow  Lot  Supervisors. 
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4.35 

SECONDARY  COLLECTIONS 
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(4.35)  SECONDARY  COLLECTIONS 


The  Vendor  selected  to  provide  the  primary  collection  services  required  under  this 
contract  will  be  given  first  consideration  to  provide  secondary  collection  services  on 
tickets  that  have  been  processed  through  the  City's  existing  collection  systems.  The 
City  has  essentially  exhausted  its  capacity  to  collect  on  certain  groups  of  tickets  and 
therefore,  is  willing  to  assign  these  tickets  for  secondary  collections.  The  Parking  Clerk 
will  have  the  sole  discretion  to  assign  tickets,  via  written  communication,  for  Secondary 
Collections.  Further,  the  Parking  Clerk,  via  written  communication  and  a  thirty  (30) 
day  notice  of  termination  of  assignment(s),  may  withdraw  from  assignment  any  and/or 
all  groups  of  tickets  at  his/her  sole  discretion  for  any  performance  related  reason 
relative  to  any  aspect  of  the  provision  of  services  required  under  the  contract  to  be 
entered  into  pursuant  to  this  RFP.  This  discretion  is  intentionally  not  limited  to  the 
performance  of  the  Vendor  relative  to  Secondary  Collections.  Vendors  will  clearly  not 
be  assigned  nor  will  they  retain  Secondary  Collection  assignments  if  the  requirements 
contained  in  the  Scope  of  Services  section  of  this  RFP  are  not  performed  in  a  qualitative 
manner  satisfactory  to  the  Parking  Clerk,  nor  will  the  Vendor  receive/retain  Secondary 
Collection  assignments  if  the  City  experiences  a  degradation  in  the  level  of  confidence 
regarding  the  Vendor's  ability  to  deliver  systems  and  services  required  in  this  RFP,  via 
the  Vendor's  failure  to  achieve  programmatic  system  development  milestones. 
Secondary  Collections  are  viewed  as  an  non-essential  component  of  the  contract. 

The  major  groups  of  tickets  that  may  be  assigned  are: 

1)  Massachusetts  registrant  tickets  which  are  over  nine  (9)  months  from  issue 
date; 

2)  Out-of- State  registrant  tickets  where  the  ticket  remains  outstanding  for  a 
time  period  of  at  least  ninety  (90)  days  following  the  mailing  of  the  last 
non-Secondary  Collections  dunning  notice.  At  present,  and  subject  to 
increase,  there  are  three  non-Secondary  Collections  dunning  notices. 
Depending  upon  circumstances,  it  is  estimated  that  these  tickets  would 
typically  be  eligible  for  noticing  four  to  six  months  following  issuance.  The 
City  reserves  the  right  to  modify  this  schedule; 

3)  Lease/Rental/Taxi  tickets  where  the  vehicle  operator  name  and  address  has 
been  secured  by  the  City  and  where  the  ticket  remains  outstanding  for  a 
time  period  of  at  least  ninety  (90)  days  following  the  mailing  of  the  last 
Lease/Rental/Taxi  vehicle  operator  dunning  notice.  At  present,  and  subject 
to  increase,  there  are  two  Lease/Rental/Taxi  vehicle  operator  dunning 
notices.  Depending  upon  circumstances,  it  is  estimated  that  these  tickets 
would  typically  be  eligible  for  noticing  four  to  six  months  following 
issuance.  The  City  reserves  the  right  to  modify  this  schedule; 

4)  Tickets  in  Non-Renewal  Status  that  have  aged  twenty-five  (25)  months 
from  the  date  that  the  non-renewal  mark  was  updated  to  the  database  in  the 
cases  of  registrations  that  are  subject  to  registration  renewal  every  two 
years,  and  tickets  in  Non-Renewal  Status  that  have  aged  thirteen  (13) 
months  from  the  date  that  the  non-renewal  mark  was  updated  to  the 
database  in  the  cases  of  registrations  that  are  subject  to  registration  renewal 
annually. 
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The  Vendor  may  be  assigned  other  groups  of  tickets  and/or  any  of  the  assigned  groups 
may  be  expanded  to  encompass  additional  tickets  and/or  time  periods. 

The  Vendor  shall  secure  the  City's  approval  in  order  to  initiate  notice  action  for  any 
group  of  tickets. 

It  should  be  recognized  that  numerous  unpaid  tickets  lack  any  or  current  addresses,  and 
the  Vendor  shall  not  be  allowed  to  utilize  any  addresses  other  than  those  addresses 
contained  on  the  PVPMISS  for  noticing  purposes. 

Payments  received  on  tickets  marked  for  non-renewal  that  are  not  in  population  '4' 
above  and  payments  received  on  tickets  on  a  booted  plate  shall  be  excluded  from 
billings.  Also,  collections  initially  paid  on  one  ticket  in  or  not  part  of  an  assigned  group 
of  tickets  and  re-distributed  to  any  ticket  in  an  assigned  group  shall  be  excluded  from 
billings.  Further,  collections  initially  paid  on  a  ticket  in  an  assigned  group  and 
redistributed  to  another  ticket  in  the  assigned  group  shall  be  excluded  from  billing  for  a 
second  time. 

The  Vendor  shall  receive  thirty-four  percent  (34%)  of  the  revenue  collected  from 
assigned  tickets. 

The  Vendor  shall  be  responsible  for  postage,  any  related  processing  costs,  and  printed 
materials  (the  form  of  which  shall  be  approved  by  the  City). 

The  Vendor  shall  provide  for  comprehensive  edits  and  controls  regarding  the 
identification  of  secondary  collections  populations  and  the  proper  treatment  and 
accounting  of  'chargeable'  and  'non-chargeable'  collections. 
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4.36 
CONVERSION 
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(4.36)  CONVERSION 


This  RFP  requires  that,  in  the  event  the  Selected  Vendor  is  not  the  Existing  Vendor,  the 
Selected  Vendor's  violation  processing  database  be  initially  loaded  from  a  master  file 
residing  with  the  Existing  Vendor's  system.  The  Vendor  shall  be  required  to  interface 
with  the  Existing  Vendor  to  conduct  conversion  activities. 


Conversion  will  be  determined  to  be  completed  when  the  system  performs  according  to 
the  standards  of  the  City.  It  will  be  the  Selected  Vendor's  responsibility  to  accomplish 
all  programming  and  testing  to  ensure  that  the  conversion  has  been  successfully 
completed.  It  will  be  the  City's/  Existing  Vendor's  responsibility  to  supply  the  data,  as 
is,  from  the  existing  parking  violations  databases  and  for  conversion  purposes  to  define 
the  storage  formats  and  describe  the  data  elements  stored  in  the  databases. 


The  Selected  Vendor  (and  by  necessity,  Prospective  Vendors)  shall  propose  a 
comprehensive  data  conversion  plan  to  convert  from  the  existing  Vendor's  system  to  the 
selected  Vendor's  system.  This  plan  shall  include,  but  not  be  limited  to,  all 
responsibilities  of  the  Vendor,  the  City,  and  the  Existing  Vendor  in  the  conversion 
effort;  how  the  conversion  will  be  accomplished;  the  conversion  timetable  and  work 
schedule;  and  how  the  accuracy  of  the  conversion  effort  will  be  measured. 


IT  SHOULD  BE  NOTED  THAT  THE  CITY  REQUIRES  A  COMPREHENSIVE  AND 
DETAILED  DISCUSSION  OF:  (A)  THE  CAPTURE  OF  DATA  TO  BE 
CONVERTED,  AND  (B)  THE  SUBSEQUENT  USE  OF  CAPTURED  AND 
CONVERTED  DATA.  Toward  this  end.  Prospective  Vendors  shall  be  advised  that  the 
data  and  information  requirements  of  the  City  set  forth  in  this  RFP  are  substantially 
representative  of  the  current  data  and  information  fields  that  would  need  to  be  captured, 
converted  and  utilized. 


Upon  completion  of  the  contract  term,  the  Vendor  shall  support  the  transfer  of  data  in 
the  event  that  the  contract  is  terminated  or  has  expired  and  a  new  Vendor  is  selected. 
Additionally,  the  Vendor  shall  be  required  to  provide  any  data  or  information  required 
by  the  City  to  prepare  an  RFP  and  execute  a  succeeding  contract,  to  include  but  not  be 
limited  to  current  and  projected  baselines,  computer  utilization,  forms  utilization, 
definition  of  storage  formats  and  description  of  data  elements  stored  in  the  databases. 
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4.37 

HAND-HELD  ELECTRONIC  TICKET  WRITING  DEVICES 


61 


62 


4.37)  HAND-HELD  TICKET  WRITING  DEVICES  (HHD's^) 


Introduction.  Background  and  Programmatic  Orientation 

The  proper  issuance  of  a  parking  ticket  with  all  data  fields  accurately  recorded  is  a 
"mission  critical"  function  relative  to  the  Parking  Violation  System  efforts  to  achieve  the 
City's  traffic  and  parking  objectives.  The  combination  of  a  clear  and  accurate  parking 
violation  and  a  comprehensive  and  efficient  Parking  Violation  System  enables  the  City  to 
efficiently  and  effectively  utilize  the  issuance  of  a  parking  ticket  as  a  meaningful 
deterrent  to  illegal  parking  upon  which  other  critical  traffic  and  parking  activities  are 
totally  dependent. 

It  is  important  for  vendors  to  understand  the  City's  perspective  on  the  need  for  a  proven, 
turnkey  HHD  system.  A  major  factor  relates  to  the  parking  ticket  issuance  process, 
particularly  the  various  issues  and  factors  impacting  the  workforce.  Some  of  these  issues 
relate  to  the  nature  of  the  workforce  while  other  issues  involve  operational  aspects  such 
as  the  requirement  that  the  work  be  performed  in  the  field.  The  work  assignment  that 
will  involve  the  deployment  of  HHD's  represents  a  difficult  setting  in  regards  to  the 
conditions  and  situations  as  well  as  the  nature  of  the  duties  and  responsibilities  associated 
with  the  performance  of  the  parking  enforcement  function. 

Obviously,  since  100%  of  ticket  writing  is  in  the  field,  environmental  conditions  greatly 
impact  the  assignment  and  performance  of  the  officers  and  the  HHD's.  Additionally,  it 
should  be  recognized  that  the  ticket  writer  is  basically  working  independently  in  the  field. 
Essentially,  the  parking  ticket  issuance  aspect  of  a  Parking  Violation/Parking 
Management  Information  Service  System  (PVPMISS)  is  the  most  challenging  and 
vulnerable  component  least  able  to  deal  with  the  potential  downside  problems  and  risks 
related  to  a  problematic  implementation  phase  of  a  new  way  of  performing  a  critical 
assignment. 

Sensitivity  &  Concern  About  Writing  a  Parking  Ticket  in  the  Field 

The  ticketing  officer's  job  may  appear  to  involve  simple  and  routine  tasks.  The 
conditions  and  situations,  however,  in  which  they  perform  this  simple  and  routine  task  as 
well  as  other  aspects  involved  in  ticket  writing  are  in  fact  challenging  and  problematic. 
Furthermore,  the  primary  function  they  perform  is  considered  "mission  critical"  for  the 
City's  Parking  Enforcement  and  Traffic  and  Parking  Management  goals  and  objectives. 
As  a  result,  major  cities  including  Boston  have  learned  to  minimize  or  eliminate  any 
unnecessary  complexity  or  confusion  and  any  'not-required'  dimension  to  the  ticket- 
writing  assignment. 

Additionally,  as  part  of  the  ticket  issuance  function,  it  is  important  to  recognize  that  the 
public's  relationship  and  feelings  about  their  motor  vehicles  and  parking  spaces  create  a 
variety  of  dimensions  and  challenges.  The  public's  issues  with  parking  in  combination 
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with  the  constant  review  and  scrutiny  by  the  media  of  anything  to  do  with  parking  and  the 
political/government  setting  of  the  operation  creates  a  need  for  the  'best/most  reliable' 
solution  approach  to  HHD's.  Numerous  examples  of  the  unique  and  hybrid 
characteristics  and  aspects  of  parking  violations  illustrate  the  complexities  and  the 
challenges  of  effective  enforcement  and  the  resultant  customer  and  adjudication  services 
needed  to  respond  to  the  justified  complaints  (due  to  errors)  as  well  as  inquiries  for 
routine  information.. 

Two  areas  that  have  a  direct  and  important  impact  on  the  public's  reaction  and  perception 
of  parking  enforcement  and  related  customer  and  adjudication  services  may  help  clarify 
the  challenges.  Basically,  the  writing  of  the  parking  ticket  and  the  registrant 
identification  process  represent  critical  and  problematic  functions  that  impact  customer 
and  adjudication  services  and  the  integrity  and  image  of  the  operation  and  of  the  City. 

(4.37.1)  The  Issuing  Officer  and  the  Parking  Violation 

The  parking  violation  is  issued  by  an  officer  that  is  willing  to  be  employed  in  a  job  that  is 
viewed  negatively  by  the  general  public  and  others.  The  actual  assignment  is  in  the  field 
performing  for  the  most  part  on  an  individual  basis.  The  job  requirements  are  minimal 
and  the  training  is  not  equivalent  to  an  academy  setting.  The  parking  ticket  is  written  in  a 
standing  position  often  in  different  types  of  inclement  weather  conditions,  and  in  the 
winter,  the  officers  wear  gloves.  In  addition  to  the  physical  and  environmental  issues,  the 
ticket  writers  are  sometimes  exposed  to  hostile  conditions  relative  to  confrontations  from 
recipients  of  the  tickets  or  from  members  of  the  general  public. 

Thus,  it  is  important  to  acknowledge  that  beyond  the  difficulties  associated  with 
conditions  and  situations  surrounding  the  writing  of  a  ticket,  the  issuing  officers  must 
focus  their  attention  to  the  details  relating  to  the  vehicle  and  its  registration  as  well  as  the 
regulations  and  signage.  In  regards  to  the  vehicle  and  license  plate,  many  issues  come 
into  play.  The  ticket  writer  must  often  think  about  how  to  decode/decipher  some  very 
confusing  license  plates  due  to  the  different  license  plate  types,  plate  phrases/wording, 
plate  colors,  alpha/numeric  characters  and  symbols  and  combinations  created  by  the 
Massachusetts  Registry  of  Motor  Vehicles  and  other  out-of-state  Motor  Vehicle 
Departments.  In  many  cases,  these  license  plates  appear  to  be  conflicting  or  at  least 
confusing  as  they  have  the  same  actual  numbers  or  letters  with  possibly  some  unique 
symbol,  color  or  other  distinguishing  feature. 

In  reference  to  the  regulations  and  signage,  the  officers  must  focus  their  full  attention  on 
the  on-street  factors  that  lead  to  proper  or  improper  issuance  of  a  violation.  These 
factors,  include  but  are  not  limited  to,  the  precise  location  of  the  vehicle  relative  to  the 
on-street  signage  that  is  intended  to  clearly  convey  the  on-street  parking  regulations  to 
the  motorists.  Due  to  missing,  confusing,  conflicting  signage  in  combination  particularly 
with  the  growing  practice  of  multiple  regulations  and/or  temporary  regulations  covering 
the  same  spaces,  enforcement  officers  must  be  keenly  aware  of  their  surrounding. 
Furthermore,  the  officers  are  responsible  for  accurately  interpreting  the  hours  of 
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operation  and  the  operational  status  of  meters,  and  they  must  be  cognizant  of  applicable 
permits  and  placards.  Thus,  issuance  of  a  parking  violation  is  not  a  simple  and  rote  task 
as  many  think,  but  on  closer  examination,  is  really  quite  complex,  in  and  of  itself. 

(4.37.2)  The  Registrant  Acquisition  Systems  and  Process  Adds  to  the  Complexity  and 
Potential  for  Problems 

Another  major  component  that  is  critically  linked  to  the  ticket- writing  activity  as 
described  above  are  the  registrant  acquisition  systems  and  processes.  There  are  different 
computer  applications  that  need  to  correctly  process  and  exchange  ticket-face  data  for 
registrant  data.  These  data  exchanges,  particularly  ones  with  out-of-state  Motor  Vehicle 
Departments,  are  pre-destined  for  potential  problems  just  due  to  the  fact  of  the  unique 
plate  features,  characters  and  interpretative  requirements.  Thus,  problems  with  ticket 
writing  can  clearly  create  the  registrant  data  acquisition  errors  that  result  in  the  wrong 
person  being  billed,  no  person  being  billed,  incorrect  data  appearing  on  a  bill  or  a  record, 
missing  data  on  a  bill  or  record,  etc.  Therefore,  inaccurate  data  capture  must  be  avoided. 
Incorrect  data  has  very  negative  operational,  cost,  image  and  integrity  consequences  for 
the  City.  The  issues  of  ticket  writing  and  registrant  identification  just  represent  a  portion 
of  challenges  that  create  a  complex  and  often  difficult  impact  on  customer  and 
adjudication  services. 

Indication  of  Impact 

To  place  the  ticket  writing  issue  and  challenge  itself  into  some  context,  just  a  3%  data 
error  rate  on  1,600,000  tickets  could  produce  48,000  legitimate  customer  disputes 
directed  at  the  City.  At  the  simplest  to  understand  level,  incorrect  information  from  the 
ticket  leads  to  misidentification  and  mis-billings,  and  subsequently  to  a  complaint,  often 
negative  and  sometime  confrontational  customer  service  and  adjudication  interaction, 
dismissal  of  the  ticket,  lost  revenue,  and  a  lost  opportunity  to  deter  illegal  parking.  This 
also  causes  the  City  to  incur  costs  associated  with  ticket  processing  and  maintenance  for 
essentially  "uncollectible"  tickets.  It  should  be  recognized  that  this  just  represents  some 
of  the  costs  and  negative  impacts  related  to  the  quality  of  ticket  issuance. 

(4.37.6)  Other  reasons  why  the  City  desires  a  successful  turnkey  HHP  system 

1)  Job  Enhancement  &  Improved  Public  Perception 

The  utilization  of  HHD's  can  provide  the  ticket  writers  with  new  skills  and 
capabilities  and  an  improved  self-perception.  It  should  be  noted  that  as  part  of 
a  recent  collective  bargaining  agreement,  the  enforcement  officers  have 
already  agreed  to  adopt  HHD's.  Also,  the  utilization  of  the  devices  should 
also  improve  the  public  image  of  the  Boston  Transportation  Department  and 
the  City's  positive  orientation  towards  using  technology  to  solve  and  address 
challenges.  For  a  function  such  as  ticket  writing,  often  berated  by  the  public, 
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a  new,  different  and  more  professional  perspective  and  public  perception  of 
their  jobs  could  provide  a  much-needed  boost  to  both  the  morale  and  self- 
esteem  of  the  enforcement  officers. 

2)  Data  Integrity/Reduction  in  Customer  Complaints 

As  noted  earlier  in  this  report,  on  an  annual  basis,  a  certain  percentage  of  all 
violations  issued  by  Parking  Enforcement  Officers  contain  missing,  illegible, 
invalid  or  wrong  information.  Since  the  HHD's  print  a  clear  digit,  accurately 
record  date  and  time,  do  not  require  data  entry  and  could  be  programmed  to 
prompt  all  fields  of  required  information,  not  only  would  the  number  of 
account  receivable  tickets  increase,  but  also  the  number  of  violator  disputes 
associated  with  questionable  data  would  decrease.  The  devices  will  hopefully 
reduce  the  number  of  tickets  assigned  to  the  wrong  registrant  due  to  ticket 
writing  and  ticket  data  deciphering  problems. 

3)  Capability  to  Enhance  Enforcement  Capabilities  and  Be  More  Productive 
The  utilization  of  HHD's  clearly  provide  an  opportunity  to  achieve  parking 
management  objectives  through  improvements  in  the  City's  enforcement 
capabilities  particularly  involving  time-based  regulations  such  as  parking 
beyond  the  limits  at  meters  or  in  1  or  2  hour  restricted  spaces.  Since  HHD's 
can  track  vehicles  with  a  simple  entry  of  a  plate  number,  an  officer  can  easily 
monitor  vehicles'  time  at  various  locations. 

4)  Access  to  Databases/Reduction  in  Customer  Complaints 

In  addition  to  issues  with  accuracy  and  interpretation  of  data,  tickets  have 
been  disputed  in  cases  where  a  customer  is  issued  a  parking  ticket  for  a 
Resident  Parking  Violation  and  they  have  a  Resident  Parking  Permit  reflected 
in  the  database.  HHD's  can  store  databases  and  access  them  to  verify  if  a 
vehicle  has  a  permit.  If  a  vehicle  has  a  permit,  we  can  avoid  issuing  a  ticket, 
receiving  a  complaint  and  then  dismissing  the  ticket. 

5)  Booting  of  Additional  Vehicles 

Each  of  the  HHD's  can  have  the  capability  to  contain  a  list  of  the  current  boot 
eligible  population  of  violators  (boot  lists),  and  a  ticket  writer  would  radio  the 
BTD  base/Tow  Lot  if  a  plate  number  on  the  boot  list  was  recorded.  If  the 
devices  are  radio  frequency  capable,  and  a  ticket  is  issued  to  a  plate  on  the 
boot  list  a  message  can  be  automatically  transmitted  (without  the  involvement 
of  the  ticket  writer)  to  the  Tow  Lot  dispatch  officer  or  a  boot  crew  apprising 
them  of  "hits"  and  the  location  of  the  vehicle.  The  "hits"  would  then  be 
verified  by  the  boot  crew  to  ensure  that  the  tickets  have  not  been  paid  since 
the  production  of  the  most  current  boot  list. 

Since  Parking  Enforcement  Officers  would  be  in  effect  acting  as  "passive 
spotters"  of  boot  eligible  vehicles  (along  with  present  Tow  Lot  personnel),  an 
increase  in  booting  and  towing  activity  may  result.  The  amount  of  increased 
booting  is  to  an  extent  subject  to  logistics  and  resource  allocation  issues. 
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6)  Turnover  Studies 

Hand-held  devices  could  also  be  used  to  conduct  turnover  studies.  The 
devices  can  record  registration  data  including  plate  number  and  plate  type. 
The  system  can  automatically  date  and  time  stamp  each  registration  record  for 
time  based  and  other  studies.  This  data  can  then  be  downloaded  to  a  PC  and 
the  registration  data  matched  against  data  contained  in  the  Parking  Violation 
System.  A  Registry  of  Motor  Vehicles  name  and  address  request  can  also  be 
generated  from  this  file  to  obtain  registration  data.  The  benefit  from  this 
option  is  that  the  labor-intensive  requirement  to  hand-write  registration 
numbers,  to  look  for  those  numbers  on  subsequent  passes,  to  perform  single 
manual  look-ups  of  the  registration  on  a  computer  terminal  and  the  recording 
of  information  is  eliminated. 

7)  Meter.  Signs.  Signal  and  Field  Service  Applications 

Hand-held  devices  could  be  utilized  for  a  variety  of  field  service  applications 
including  meter,  sign  and  signal  inventory  and  repair  calls.  Hand-held  devices 
could  be  programmed  to  record  data  that  can  then  be  updated  to  the  Meter 
Management  System,  the  Sign  Management  System  or  another  database 
indicating  outage  and  repair  data.  Management  and  operational  reports  can 
then  be  generated  detailing  a  wide  range  of  information. 

It  is  expected  that  hand-held  devices  used  for  field  service  applications  would 
not  require  radio  frequency  capability. 

8)  Ambassadors  for  the  City 

Since  the  officers  are  in  uniform,  tourists  and  others  frequently  ask  them  for 
directions  and  request  other  information.  The  HHD's  could  provide  directional 
and  possibly  information  on  other  commonly  asked  questions. 

9)  A  Management  Tool 

Hand-held  devices  have  the  capability  to  store  information  concerning  the 
activity  of  the  agent  utilizing  the  device  such  as  the  total  number  of  tickets 
written,  total  number  of  each  violation  type  written,  "time-outs"  taken  for 
lunch  and  breaks,  etc.  From  this  stored  information,  MIS  Reports  can  be 
produced  which  will  allow  management  personnel  to  monitor  an  officer's 
productivity  and  activity  on  a  timely  basis.  Route  analysis  and  deployment 
can  then  be  analyzed  and  refined  based  on  this  data  collection  and  reporting. 

(4.37.7)  City's  Orientation  and  Key  Objectives  for  HHD's 

With  very  high  ticket  issuance  numbers,  a  successful  low-cost  efficient  but  responsive 
and  effective  customer  service  operation,  and  a  very  high  collection  rate  with  an 
associated  revenue  stream  involving  tens  of  millions  of  dollars,  the  City  can  not  and  will 
not  entertain  the  introduction  of  any  new  technology  that  can  create  potential  risk  and 


67 


disruption  to  the  levels  and  quality  of  its  PVPMISS  operation.  It  is  absolutely  critical  to 
use  proven  technology  and  to  keep  the  ticket-writing  assignment  at  a  basic  and  simple 
level.  The  City  is  directly  looking  for  the  HHD  that  will  immediately  and  simultaneously 
further  enhance  our  operational,  customer  service  and  enforcement  capabilities  and 
effectiveness  while  reducing  customer  service  and  other  costs  and  increasing  revenue  and 
improving  collection  rates.  As  noted,  our  Enforcement  Officers  already  have  a  difficult 
assignment  that  is  constantly  becoming  more  complex.  Thus,  we  desire  to  make  part  of 
their  job  easier  and  better  for  them,  for  our  customers  and  for  the  achievement  of  parking 
management  objectives. 

Thus,  the  City  in  a  similar  manner  to  other  major  cities  in  this  and  other  countries 
requires  and  mandates  that  the  HHD's  be  ruggedized,  fully  tested,  debugged,  proven  in 
major  urban  city  production  environments,  and  determined  to  be  completely  reliable  for 
the  basic,  repetitive  task  of  entering  standard  information  and  generating  a  parking  ticket. 
Further,  due  to  the  large  number  of  potential  users  with  varying  backgrounds  relative  to 
computer  usage,  the  HHD  should  be  designed  to  require  an  extremely  minimal  degree  of 
technical  dexterity  for  operation.  Additionally,  for  labor  force  and  various  operational 
reasons  including,  but  not  limited  to,  weather  and  clothing,  the  City  is  requires  and 
mandates  a  combined,  one  (1)  or  wireless  two  (2)  piece  design  for  the  issuing  device  and 
the  printing  device.  The  selected  vendor  will  also  be  required  to  have  a  well-established 
reputation  that  can  be  substantiated  and  documented  as  a  subject-matter  experienced 
vendor  in  providing  proven  HHD's  for  on-street  parking  solutions  with  extensive  and 
specialized  experience,  knowledge,  abilities  and  skills  for  parking  ticket  issuance 
enforcement  and  parking  management  applications  in  large  urban  environments. 
Moreover,  the  selection  of  a  vendor  will  also  be  subject  to  the  vendor's  ability  to 
substantiate  and  document  its  capabilities  to  provide  a  reliable  and  ready  to  use,  at  the 
start  of  the  contract,  turnkey  HHD  system  (with  proven  products,  systems  and  services). 
Additionally,  as  part  of  RFP  submission,  the  vendor  must  clearly  demonstrate  and 
substantiate  its  hardware,  software,  existing  specifications,  and  related  equipment  and 
service  ability  and  capabilities  to  avoid  a  development  process  during  the  initial 
deployment  of  the  HHD.  The  BTD,  other  than  providing  prior  to  the  start  of  the  contract 
routine  information  such  as  violation  codes,  penalty  amounts,  and  meter  numbers,  is  not 
responsible  for  providing  functional  specifications  and  user  requirements. 

First  and  foremost,  the  BTD  is  responsible  for  the  enforcement  of  parking  regulations  and 
customer  service,  adjudication  and  collection  of  parking  tickets.  Therefore,  again,  our 
primary  focus  is  on  our  foot-patrol  labor  force,  and  the  issue  is  on  the  complete  HHD 
operation  and  systems  that  are  most  suitable  and  appropriate  for  our  ticket  writers,  our 
customers  and  our  customer  service  and  adjudication  staff.  We  have  a  diverse  workforce 
that  are  not  computer  technicians,  and  therefore,  the  HHD's  must  be  designed  and 
oriented  towards  that  labor  force.  The  City  requires  and  mandates  HHD's  that  users  will 
find  user  friendly  and  will  not  cause  user  frustration,  down-time,  problematic  debugging, 
testing,  etc.  Our  ticket  writers  need  tried,  true,  tested,  proven  and  complete  HHD  system 
and  operation.  Additionally,  the  City  can  not  and  will  not  suffer  loss  of  ticket  issuance 
(and  the  resulting  loss  of  revenue),  "turn-off"  of  users  while  they  test,  debug,  and  revise 
software  and  hardware  issues,  and  just  as  importantly,  we  do  not  want  to  add  to  our 
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customer  service  problems  by  providing  poor  quality  or  erroneous  tickets  to  our 
customers  that  produce  more  complaints  and  stress  for  our  customer  service  and 
adjudication  staff.  Thus,  Boston  and  other  major,  urban  cities  with  high  volume  issuance 
are  avoiding  systems  development  projects  and  cutting/bleeding-edge  technology  due  to 
the  reasons  cited  above.  It  is  in  the  best  interest  of  the  City  to  ensure  that  the  introduction 
of  new  ticket  issuance  technology  is  successful  from  the  beginning  of  the  process. 

While  on  one  hand  we  are  focused  on  securing  the  proven  HHD's  from  subject  matter 
experienced  providers  due  to  various  workforce  factors,  we  are  also  oriented  towards 
subject-matter  expertise  for  other  critical  reasons.  The  other  reasons  include  the  reaction 
of  the  general  public  to  parking  tickets  as  well  as  the  scrutiny  from  the  media  and  other 
sources  (e.g.,  political  representatives  of  constituents).  Cities  including  Boston  have 
recognized  that  the  writing  of  the  parking  violation  is  a  challenging  function  in  an  urban 
environment.  We  believe,  fortunately  for  the  City  of  Boston,  that  this  focus  and 
orientation  towards  proven  technology  for  the  task  of  ticket  issuance  has  been  facilitated 
by  the  development  of  true  subject  matter  expertise  by  providers  of  HHD's  in  other  major 
cities. 


(4.37.8)  Vendor  Provision  of  HHD's 

The  Vendor  shall  be  responsible  for  providing,  implementing  and  supporting  portable 
data  terminals  with  combined  (i.e.,  one  piece  or  wireless  two  piece)  integrated  printers 
(HHD's),  base  stations  and  any  and  all  hardware,  including  installation  and  site 
preparation,  necessary  for  the  optimal  performance  of  such  devices  (herein  after  referred 
to  as  'HHD's)  as  a  primary  means  of  issuing  parking  tickets.  The  estimated  220  to  260 
City  of  Boston/BTD  Parking  Enforcement  Officers  that  will  be  assigned  devices  issue 
approximately  90%  of  the  tickets  issued  in  Boston.  The  City's  objective  for  automating 
the  ticket  issuance  process  is  to  enhance  the  quality  of  the  parking  tickets  issued  by 
Parking  Enforcement  Officers  and  to  improve  the  efficiency  of  effectiveness  of  the 
enforcement  capabilities.  The  City  may  require  HHD's  in  the  future  to  be  capable  of 
utilizing  various  technologies  such  as  wireless  (radio  frequency)  transmission  to  the 
Vendor's  host  computer  for  selected  parking  ticket  data  and  scanning  of  vehicle 
information  (i.e.  via  barcode  or  similar)  from  inspection  or  other  stickers.  In  all  cases, 
however,  HHD's  shall  be  capable  of  retaining  parking  ticket  data  in  the  device  for  later 
transmission  to  the  Vendor's  host  computer  system  in  the  event  of  transmission 
interruptions  should  the  City  utilize  this  communication  option. 

Prospective  Vendors  are  directed  to  refer  to  the  entire  section  of  this  RFP  entitled 
"Parking  Ticket  Pick-up  Receipt  and  Control",  and  in  particular,  subsection,  "Issuance 
Profile",  and  the  entire  section  of  this  RFP  entitled  "Parking  Ticket  Data  Entry",  and  in 
particular,  subsection,  "Information  Foundation  and  Zero  Defect  Objective",  for 
information  and  requirements  relative  to  ticket  issuance  and  update  and  the  entire  section 
of  this  RFP  entitled,  "Lockbox  Processing  Functions",  and  in  particular  subsection.  As 
well  as  the  scanning  of  barcodes  affixed  to  the  Resident  Parking  Permit  for  the  purpose  of 
Resident  Parking  Permit  number  validation  and/or  other  uses. 
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"Lockbox  Processing  Overview",  for  information  and  requirements  relative  to  ticket 
issuance,  update  and  automated  (OCR)  payment  processing. 

The  Vendor  shall  identify  in  detail  how  it  will  comply  with  the  requirements  stated  in  this 
section.  Further,  the  Vendor  shall  identify  in  detail  how  it  will  support  this  specific 
application  with  technical  staff  including  staff  that  will  be  available  to  be  on-site  for 
installation,  including  site  preparation,  training,  and  start-up  as  well  as  on  an  on-going 
basis  throughout  the  life  of  the  contract  entered  into  pursuant  to  this  RFP.  HHD  support 
personnel  shall  have  current  industry  certifications  and  appropriate  experience  to  fully 
support  all  networking,  hardware  and  software  platforms  utilized.  Hand-held  support 
personnel  shall  be  responsible  for  coordinating  system  modifications  with  City  staff  (as 
well  as  any  paper  and/or  envelope  suppliers  utilized  by  the  City)  and  contractor  technical 
personnel,  troubleshooting  problems  including  hardware  and  application  problems,  and 
training  City  staff.  The  Vendor  shall  be  responsible  for  ensuring  accurate,  automated 
payment  process  of  HHD  issued  parking  tickets  via  the  Vendor's  Lockbox  processing 
facility  and  equipment.  The  Vendor  shall  provide  the  City  with  an  implementation  plan 
to  ensure  a  smooth  implementation  of  the  hand-held  technology  as  proposed. 

Equipment  Requirements 

Although  current  deployment  levels  are  discussed  elsewhere,  the  Vendor  shall  be 
responsible  for  providing  a  minimum  of  two  hundred  fifty  (250)  HHD's  with  all  required 
hardware,  software  and  other  equipment  and  services  to  support  ticket  issuance  by  the 
Boston  Transportation  Department's  Parking  Enforcement  Officers. 
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Repairs  and  Replacement  of  the  HHP's  and  Supporting  Equipment 

The  Vendor  shall  provide  repairs  and  full  replacements  for  all  hand-held  devices, 
including  printer  components,  damaged,  lost  or  otherwise  rendered  inoperative,  for  any 
reason.  The  Vendor  shall  replace  devices  determined  by  either  the  hardware  supplier  or 
the  City  to  be  beyond  repair.  Such  replacement  devices  shall  be  new  and  shall  be  fully 
configured  and  operational  when  delivered  to  the  City.  The  Vendor  shall  refer  to  the 
section  of  this  RFP  entitled  "Network  Capabilities  and  Other  Equipment,  Service  and 
Supply  Requirements"  for  a  further  discussion  of  service  requirements.  Ownership  of  all 
hardware  and  software  associated  with  such  hand-held  devices  should  become  the 
property  of  the  City  at  the  conclusion  of  any  contract  entered  into  pursuant  to  this  RFP. 

Transmission  Cradles/Devices  and  Chargers 

The  Vendor  shall  be  responsible  for  supplying  sufficient  cradles,  chargers,  docking 
stations  or  the  like,  to  support  the  hand-held  devices.  The  chargers  and  cradles  shall  be 
connected  to  the  minimum  number  of  base  stations  to  allow  for  optimal  transmission  of 
data  and  unit  charging  with  minimal  processing  time.  Wireless  Technology  application  is 
required. 


Batteries 

The  Vendor  shall  be  responsible  for  supplying  sufficient  batteries  to  support  the  hand- 
held devices.  This  shall  include  spare  batteries  to  allow  for  battery  change-outs  as 
necessary.  The  Vendor  shall  specify  minimum  battery  life  standards.  An  external, 
charging  cradle,  used  to  charge  the  batteries  while  they  are  in  the  unit  shall  be  provided. 
Rechargeable  battery  packs  must  be  able  to  provide  power  for  a  minimum  of  eight  (8) 
hours  of  continuous  usage  in  a  parking  enforcement  environment  without  changing  or 
recharging  batteries.  The  system  must  have  a  power  saver  feature  that,  when  the  system 
is  operating  on  batteries,  automatically  goes  into  "sleep"  mode  after  a  period  of  idle  time, 
which  can  be  specified.  The  Vendor  shall  provide  a  battery  analyzer/tester  for  use  with 
all  batteries  required  for  operation  of  any  HHD  provided. 

Interface  Capability.  Communication.  Connectivity.  Downloading.  Uploading 

The  Vendor  shall  be  responsible  for  providing  all  interface  and  network  capability 
between  the  base  stations,  the  Vendor's  processing  location(s)  and  the  hand-held  devices. 
The  system  must  offer  the  capability  of  direct  host  communication  with  multiple  hand- 
held units  that  allows  for  simultaneous  data  transfer  to  multiple  hand-held  devices  in  a 
totally  automated  fashion  via  a  minimum  number  of  base  stations.  The  system  will 
provide  the  customer  the  capability  of  placing  the  target  workstation  into 
communications  mode  allowing  the  hand-held  devices  to  be  wirelessly  uploaded, 
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downloaded  and  charged  any  time  without  user  intervention.  The  Vendor  shall  be 
required  to  provide  a  daily,  automated  download  routine  to  provide  the  list  of  seizure 
eligible  vehicles  to  all  hand-held  devices.  Please  refer  to  the  section  of  this  RFP  entitled 
"Boot  and  Tow  System"  for  a  description  of  the  City's  seizure  program.  The  Vendor 
shall  also  be  required  to  provide  on  a  routine  basis  as  specified  by  the  City,  an  automated 
download  routine  to  provide,  for  example,  a  list  of  vehicles  which  have  received  a 
resident  parking  permit  in  the  City  of  Boston  and  possibly  a  stolen  vehicle  hot  list. 
System  performance  of  the  hand-held  devices  in  terms  of  ticket  issuance,  response  time, 
printing,  data  transmission  of  parking  ticket  data,  etc. . .,  shall  not  be  adversely  affected  by 
the  download  and  residence  of  the  data  files  listed  above.  The  software  shall  incorporate 
auto  recovery  techniques  in  cases  of  communications  failure.  Capability  for  officers  to 
complete  the  data  transfer  operation  from  a  remote  site  by  modem  shall  be  provided. 
Units  should  have  a  PCMCIA  slot  that  must  support  additional  data  storage  and 
connectivity  of  peripheral  equipment  such  as  printers,  cellular  modems,  or  bar  code 
readers.  The  PCMCIA  shall  be  easily  accessible  to  the  user  of  the  system. 


Data  Export/Import 

The  software  must  be  capable  of  creating  file  formats  that  readily  facilitate  and 
accommodate  data  import/export  between  all  aspects  of  the  parking  management  system 
and  external  agencies 

(4.37.9)    Development  of  Additional  Applications  or  Enhancements 

The  Vendor  may  also  be  required  to  develop  additional  applications  or  enhancements  to 
the  hand-held  system.  These  may  include,  but  are  not  limited  to,  parking  meter  inventory 
data,  enforcement  route  surveys  and  turnover  studies,  field  investigations  and  data 
collection  on  missing  signage  or  road  conditions,  and  customer  service  information  such 
as  maps  for  tourists  to  popular  attractions  in  the  City. 

Reporting  Including  Ad  Hoc  Capabilities 

The  HHD  and  system  shall  provide  a  wide  variety  management  reports,  in  electronic  and 
hard  copy  form  as  specified  by  the  City,  on  an  individual  user  basis,  user  group  basis  or 
other  basis  according  to  the  data  components  captured,  for  analysis  and  activity  reporting. 
The  Vendor  shall  provide  a  centralized  ad  hoc  reporting  server  and  database.  The 
Vendor  shall  ensure  that  hand-held  and  base  station  generated  data  is  in  a  format 
available  for  ad  hoc  analysis  at  the  desktop  level  (i.e.,  the  data  can  be  accessed  and 
extrapolated  by  all  authorized  networked  PC  users).  Issuance  data  shall  automatically 
update  the  ad  hoc  reporting  server  and  database.  The  database  shall  be  accessible  from 
any  PC  workstation  connected  to  the  network.  The  Vendor  shall  provide  a  user-friendly, 
operationally  efficient  ad  hoc  reporting  writer  and  query  tool,  which  allows  users  to 
perform  ad  hoc  queries  based  on  any  available  data  fields  for  any  date  range.  The  query 
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tool  must  allow  data  to  be  sent  to  a  printer,  file,  or  screen  display.  The  Vendor  shall 
provide  a  database  dictionary  which  describes  each  data  field  in  the  ad  hoc  reporting 
database  by  listing  field  names  and  their  corresponding  textual  descriptions. 
Various  report  capabilities  must  be  available  from  the  system.  By  way  of  illustration, 
these  reports  would  include  an  officer  specific  report  of  tickets  written  by  location,  time 
of  day  and  violation  type  over  a  date  range;  a  chronological  listing  of  citations  written  by 
violation  type,  location  and  date  range. 


Security 

The  system  must  allow  the  creation  of  a  profile  for  each  individual  user.  This  profile 
must  specifically  detail  the  access  rights  and  security  privileges  as  defined  by  the  system 
administrator.  At  a  minimum,  there  must  be  three  levels  of  password  protected  user 
logins  —  1  for  officers,  1  for  supervisors  and  1  for  an  administrator  with  ability  to 
configure  devices.  Access  levels  should  include  the  ability  to  specify  read  only  access, 
ability  to  insert  records,  ability  to  edit  records,  ability  to  delete  any  record,  ability  to 
delete  only  your  records,  and  no  delete  capabilities  whatsoever.  The  system  must  also 
provide  a  complete  audit  trail  of  every  modification  or  transaction  executed  by  a 
particular  user. 


(4.37.18)  Ticket  Information  to  be  Captured  by  HHP  (to  include  but  not  limited  to) 
The  following  basic  information  will  be  stored  in  the  hand-held  device: 

•  Unique  ticket  number  (mod  formulation  to  be  determined  by  City) 

•  Issue  date  (automatic  entry) 

•  Issue  time  (s)  (time  of  issuance  via  automatic  entry) 

•  State 

•  Registration  number  and/or  VIN# 

•  Plate  Color 

•  Plate  Type 

•  Vehicle  Make 

•  Vehicle  Color 

•  Vehicle  Type 

•  Location 

•  Parking  meter  number 

•  Route 

•  Division  (automatic  entry) 

•  Zone  (15min,  30min,  lhr,  etc.) 

•  Issuing  Officer  Name 

•  Issuing  Officer  Badge  Number 

•  Violation  Identification  Code  and  Phrase  (s)  with  possible  additional  description 
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•  Fine  Amount 

•  Officer  Notes 


(4.37.19)  HHP  Capabilities  for  Turnkey  System  (to  include  but  not  limited  to) 
Extensive  scrollable  comments/history  field 

The  software  shall  be  capable  of  recording  information  on  infractions  and  printing  of 
Parking  Tickets  and  other  data  as  required  (i.e.,  informational  maps). 
Use  of  system/login  information  to  auto-fill  fields  such  as  Date,  Time,  User  ID  /Officer 
number,  routes,  initials,  etc. 

Simple  prompts  to  enable  officer  to  enter  ticket  information.  Data  entry  should  be 
intuitive  and  at  no  time  during  citation  entry  must  the  officer  memorize  codes  for  data 
entry;  all  entries  must  be  selectable  from  a  list  or  menu  and  follow  a  logical  system  flow. 
Use  of  alpha-numeric  search  for  look-up  and  selection. 

Include  means  of  tracking  vehicles  in  a  Timed  Zone  (and  advise  officers  of  vehicles  in 
violation).  The  application  must  keep  track  of  the  original  time  the  vehicle  is  'timed' 
and  record  it  on  the  ticket. 

Ability  to  download  scofflaw  information  to  hand-held  citation  units  and  link/identify  a 
vehicle  as  a  seizure  eligible  scofflaw.  Ability  to  automatically  search  databases 
containing  plate  numbers,  then  instantly  alert  the  officer  to  habitual  offenders,  stolen 
vehicles,  or  exempt  vehicles.  The  appropriate  message  is  displayed  on  the  screen 
allowing  the  officer  to  take  immediate  action  by  notifying  the  Tow  Lot  Base  Station  for 
towing  or  other  special  handling.  The  message  may  also  be  audible,  alerting  the  officer 
to  the  vehicle's  scofflaw  status. 

Ability  to  download  Resident  Permits  and  associated  vehicle  registrations  and  link 
vehicles  on  the  street  to  permit  numbers.  Ability  to  search  databases  containing  newly 
cancelled/expired  or  issued  parking  permits. 

Listing  of  all  prior  citations  and  ability  to  display  any  previous  citations  within  a  given 
time  range,  such  as  24hrs,  72hrs,  5  days,  etc. 

Allowing  additional  descriptive  information  to  be  entered  for  qualifying  the  "Location" 
field. 

Allowing  manual  data  entry  to  supplement  the  selection  in  some  fields. 

A  selection  made  in  a  primary  field  such  as  an  Offense  to  trigger  automatic  updating  of 

dependent  fields  (e.g.  meter  violations  require  meter  numbers). 

Ability  to  change  the  status  of  a  citation  including  an  auditable  void  function  and  reason 
for  void,  however,  this  will  be  ID  dependent. 

Ability  to  track  all  changes  and  adjustments  made  to  a  record  to  a  specific  individual, 
date  and  time. 

Be  able  to  restrict  full  data  edit  and  delete  capabilities  only  to  authorized  individuals. 
Ability  to  scan  bar  codes  or  RFID  tags  for  Resident  Permits,  Inspection  Stickers,  etc.. 
Ability  to  transmit  by  Radio  Frequency  any  of  the  data  captured  by  the  HHD's. 
The  software  must  allow  the  supervisors  to  select  whether  the  license  plate  must  be 
entered  twice  in  the  field  for  confirmation  and  reduction  in  data  entry  errors. 
Where  plate  number  is  not  available,  providing  alphanumeric  field  for  (VIN  #) 
information. 
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Provide  an  area  for  recording  comments  (public/private). 
User  confirmation  prior  to  printing. 

Ability  to  change  the  data  entered  into  the  hand-held  device  before  printing. 
OCR  and/or  and  Barcode  printing  of  the  ticket  number. 
OCR  and/or  Barcode  payment  processing  of  hand-held  device  produced  tickets 
Ability  to  reprint  any  ticket  or  data. 

Ability  for  the  user  to  record  that  a  ticket  was  issued  but  was  not  served. 

Ability  to  house  camera,  take  and  record  digital  pictures  for  capturing,  transmitting  and 

storing  such  pictures  in  the  appropriate  systems  fro  retrieval  and  documentation  of  the 

tickets,  plates,  vehicles,  signs  and  additional  images  required  to  be  captured. 

The  Vendor  shall  provide  training  for  parking  enforcement  personnel  relative  to  image 

capture.  All  images  shall  be  date/time  stamped. 

Ability  to  house  and  have  GPS  (Global  Positioning  System)  capability  for  the  purpose  of 
tracking  handheld  units. 

Hardware  for  this  purpose  should  be  included  in  the  unit  at  time  of  purchase  so  that  this 
option  feature  could  be  activated,  if  and  when  the  City  desires  to  use  this  technology. 
Handheld  issued  citations  determined  to  be  void  by  the  BTD  shall  be  excluded  from 
billing  by  the  Vendor.  The  Vendor's  billing  software  shall  be  capable  of  reflecting  the 
accurate  count  of  void  hand-held  issued  citations  and  billing  records  submitted  to  the  City 
shall  reflect  this  count. 

(4.37.20)  Other  Requirements 

1)  Software 

The  software  must  conform  with  the  City's  system  specifications  for  the 
location.  The  software  must  conform  with  the  City's  system  specifications  for 
the  Parking  Enforcement  Log-In-Table.  The  software  must  conform  with  the 
City's  system  specifications  for  the  Meter  Number  Table. 

2)  Physical/Environmental  Characteristics 

The  unit  must  be  capable  of  being  stored  without  damage  within  the 
temperature  range  of  -40  to  120  degrees  F. 

Hand-held  device  must  be  lightweight,  (including  batteries)  to  avoid  user 
fatigue.  It  must  be  possible  for  the  average  person  to  hold  the  system  unit  easily 
in  one  hand  for  extended  periods  of  time. 

The  hand-held  device  must  be  waterproof  and  dustproof  and  capable  of 
withstanding  repeated  drops  to  concrete  from  a  height  of  3  feet. 

3)  Processor  &  Memory 

The  hand-held  device  at  a  minimum  must  have  sufficient  Static  RAM 
memory. 

Unit  must  have  the  ability  to  be  upgradeable. 

The  system  processor  must  function  with  sufficient  MHz. 

4)  Operating  System 

Standard  operating  system  such  as  WINDOWS,  Win  CE,  Windows  Mobile  or 
PalmOS. 
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5)  Keyboard/Screen 

Proposed  machines  will  be  evaluated  for  interface  quality.  While  it  is  not 

possible  at  present  to  define  quantitative  specifications  for  these  characteristics, 

they  are  of  substantial  importance  to  the  usability  of  the  product.  In  particular, 

the  interface  must  encourage  efficient  navigation  within  the  application. 

It  must  be  possible  to  utilize  the  interface  while  wearing  winter  gloves  in  cold 

weather,  without  inadvertently  hitting  any  other  key. 

Interface  must  offer  tactile  and/or  audible  feedback. 

The  display  screen  must  be  a  backlit,  shock-resistant,  liquid  crystal  screen  and 
support  at  least  160X160  pixels  with  a  backlit  display  with  adjustable  font 
sizes.  Displays  should  provide  crisp  characters  that  are  easy  to  read.  Display 
should  not  reflect  glare  from  overhead  lighting  or  other  light  sources.  The 
display  must  be  non-fatiguing  so  that  it  can  be  used  for  an  extended  period  of 
time  without  eye  discomfort  to  the  operator.  Where  applicable  multiple 
Enter/Return  Keys  for  ergonomic/left  handed  users. 

6)  Printer 

Unit  must  permit  the  use  of  an  integrated  printer  that  physically  is  part  of  a 
one  piece  HHD. 

The  printer  must  be  fully  compatible  with  the  hand-held  device  and  the 
Parking  Enforcement  Software. 

The  unit  must  be  capable  of  being  stored  without  damage  within  the 
temperature  range  of  -40  to  120  degrees  F. 

The  print  head,  connectors,  and  electronics  must  be  sealed  to  protect  against 
moisture. 

The  printer  must  be  unaffected  by  humidity.  Printer  must  be  capable  of  printing 
in  the  rain. 

The  field  printer  must  be  capable  of  printing  an  official  looking  form. 
The  printer  must  be  capable  of  printing  enlarged,  emphasized,  and  condensed 
characters;  sideways  and  upside  down  fonts;  and  programmable  graphics. 
The  printer  must  be  able  to  print  machine-scannable  bar  codes  and  other 
characters,  such  as  OCR. 

The  ticket  design  and  print  layout  shall  allow  for  the  minimum  print  speed. 
The  print  speed  must  be  such  that  an  8-inch  form  can  be  printed  in  20  seconds 
or  less. 

The  image  printed  onto  the  form  must  remain  legible  and  not  smear  when  the 
form  becomes  wet. 

Ability  to  print  on  coated/waterproof  paper. 

7)  Tickets/Printer  Supplies 

Providing  all  paper  and  envelopes  and  any  other  supplies  to  render  hand  held 
devices  fully  operational  for  the  duration  of  the  contract  entered  into  pursuant 
to  this  RFP.  A  waterproof  envelope,  used  by  the  public  to  remit  payment  or  to 
send  a  dispute,  will  accompany  all  issued  violations.  Envelopes  will  be  of  a 
color  and  size  specified  by  the  City.  The  envelopes  will  include  an  address  to 
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a  Post  Office  Box  with  barcode,  an  area  for  a  return  address  and  an  area  for  a 
postage  stamp. 

The  Vendor  shall  identify  a  minimum  of  three  (3)  suppliers  of  paper  and 
envelopes.  The  City  may  also  require  the  Vendor  to  disclose  the  cost  of  such 
items. 

8)  Training 

Provide  an  appropriate  amount  of  on-site  training  for  employees  at  time  of 
implementation. 

Offer  follow-up  training  10-12  weeks  after  software  installation. 
Provide  on-site  ongoing  refresher  training  at  intervals  determined  by  the  City. 
Provide  skill/user  specific-training  for  new-hire  Parking  Enforcement 
Officers,  existing  officers,  supervisors,  and  City  administrators. 

9)  Handheld  Units  for  Tow  Truck  Drivers 

The  Vendor  shall  supply  Ruggedized  Handheld  units  for  Tow  Truck 
Operators  for  the  purpose  of  photographing  vehicles  in  the  field  before 
towing,  for  damage  control  documentation  and  relationship  to  the  vehicle 
being  parked  with  regard  to  the  posted  violation.  The  Vendor  shall  develop  an 
electronic  form  to  replicate  the  current  Vehicle  Condition  Report  (VCR)  and 
the  appropriate  software  development  to  facilitate  issuance  of  the  VCR 
relative  to  towing  policies.  All  appropriate  timestamps  to  document  the 
towing  procedure  and  events  shall  be  recorded.  Upon  arrival  at  the  tow  lot, 
information  shall  be  wirelessly  transmitted  to  the  Parking  Management  Boot 
&  Tow  subsystem  and  the  appropriate  records  updates  made.  Images  shall  be 
stored  and  catalogued  to  the  appropriate  record.  An  electronic  form  of  the 
VCR  shall  be  associated  with  the  record  that  will  also  be  printed  for  further 
processing  of  the  towed  vehicles.  The  printed  forms  will  be  bar-coded  to 
ensure  accurate  processing  and  completion  of  records,  and  shall  include  the 
necessary  and  corresponding  information  and  timestamps.  The  printed  form 
will  have  the  capability  to  print  the  appropriate  corresponding  images. 
Information  captured  shall  be  populated  in  the  Vendor's  Parking  Violation 
System. 

Maintenance  Contract 

The  Vendor  shall  provide  access  to  a  staffed  Help  Desk  Call  Center  to  report  a  problem 
from  6:00  am  to  7:00  pm  Eastern  Standard  Time,  7  days  a  week  (this  time  is  subject  to 
change  if  the  hours  of  enforcement  are  changed). 

Turn  around  time  of  48  hours  for  replacement  equipment;  if  repair  is  longer,  new  and 
fully  configured  HHD's  ready  for  service  upon  receipt. 

Maximum  response  time  of  four  hours  for  support  calls  placed  or  by  7:00  pm  EST. 
Software  upgrades  shall  be  scheduled  at  an  operationally  and  efficient  time  and  approved 
by  the  City. 
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The  Vendor  shall  provide  a  schedule  for  preventative  maintenance  by  manufacturer  or 
certified  technician  (minimum  twice  yearly). 

Warranty 

The  Vendor  shall  supply,  through  the  manufacturer,  a  standard  manufacturers  (12  month) 
warranty  covering  all  Parts  and  Labor  for  all  hardware  and  software  proposed.  In 
addition,  the  Vendor  shall  provide  a  maintenance  agreement ,  from  the  manufacturer,  for 
the  life  of  the  contract  with  terms,  pricing  and  repair/replacement  of  units  that  are 
defective,  subject  to  the  Cities  selection/approval.  Such  maintenance  agreement  shall 
cover  the  life  of  the  product  and  all  parts  and  repairs. 

The  Vendor  shall  be  responsible  for  shipping  charges  on  all  hardware  and  software 
covered  by  the  warranty. 

Documentation 

A  pre-installation  visit  is  required  to  determine  site  preparation  requirements  for 
implementation  and  training.  The  results  of  this  visit  should  facilitate  an  accurate 
timetable  for  total  implementation  in  terms  of  time,  cost,  and  other  variables.  The 
following  documentation  must  be  available  at  the  time  of  delivery/contract  execution: 

•  Technical  reference  manual,  which  describes  in  detail  all  of  the 
hardware.  The  manual  must  include  a  general  description  of  major 
components  of  the  system.  The  technical  manuals  must  be  published  by 
the  original  equipment  manufacturer.  Any  third  party  components  must 
also  be  documented  to  the  same  level  of  detail  and  included  as 
appendices  in  the  technical  manual.  The  manual  must  be  available  in 
English. 

•  A  minimum  of  two  operator/user  manuals  which  consists  of  at  least  the 
following: 

User  and  reference  materials  for  all  hardware/software  options. 
Documentation  for  power  and  environmental  requirements. 
Reference  manuals  for  diagnostics  and  power-on  self-test. 
Complete  installation  instructions  and  configuration  description. 
Complete  preparation  and  packaging  instructions  for  shipping  and 
transport. 

Technical  Support  &  Development 

The  Vendor  shall  provide  on-going  technical  support  and  problem  solving  as  needed 
throughout  the  life  of  this  contract. 
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The  Vendor  shall  work  with  the  City  in  the  development  of  Geographic  Information 
System  (GIS)  applications  for  the  hand-helds  and  other  associated  databases. 

Environmental  Issues  at  the  Tow  Lot  Facility 

The  Vendor  will  be  responsible  for  site  preparation  including  installation  of,  at  a 
minimum:  networking  communications,  base  stations,  docking  stations,  report  printers, 
electrical  power  supply  and  surge  protection,  coolant  units,  etc.  Base  stations/docking 
stations  shall  be  fully  functional  when  installed  and  require  minimal  training,  for  City 
staff  to  maintain  and  operate.  The  Vendor  shall  be  on-site  for  daily  uploads/downloads 
and  charging  as  required  to  ensure  optimal  system  performance. 

(4.37.26)  Additional  HHP  Requirements 

The  Vendor  must  submit  a  design  document  describing  hardware  and  software 
specifications  prior  to  system  implementation. 

Such  devices  shall  have  an  economically  correct  carriage  and  operation  by  left  or  right- 
handed  personnel  and  must  include  a  carrying  strap  or  other  device  to  minimize  fatigue. 

The  screen  must  be  clearly  readable  in  direct  sunlight  and  after  exposure  to  direct 
sunlight. 

The  display  keys  must  have  sufficient  automatically  adjustable  lighting  to  facilitate  use 
after  dark  and  whenever  low  lighting  conditions  exist. 

Such  devices  shall  include  a  real-time  standard  clock  to  provide  date  and  time  stamps  for 
all  operational  functions. 

Application  software  shall  use  the  computers  real  time  (standard)  clock  to  provide  date 
and  time  stamps  for  all  operational  functions  including  vehicle  registration  number 
observations,  over-timing  of  vehicles  at  meters  and  for  time-based  observation  for  ticket 
issuance.  The  internal  clock  shall  be  synchronized  on  a  daily  basis  with  the  host  pc. 

The  application  must  automatically  synchronize  the  date  and  time  between  base  station(s) 
and  hand-held  devices  on  a  daily  basis. 

The  system  must  automatically  adjust  to  daylight  savings  /  standard  time  changes  without 
any  manual  intervention.  Daylight  savings  /  standard  time  changes  shall  be  automatically 
reflected  on  all  hand-helds. 

The  Vendor  shall  state  maximum  battery  charge  times. 
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The  Vendor  shall  state  maximum  download  and  upload  of  data  times  and  shall  indicate  if 
such  data  transmission  can  be  accomplished  simultaneously  with  battery  charging  and 
other  application  synchronization  functions  (i.e.,  update  of  violation  codes,  fine  amounts, 
etc.). 

The  Vendor  shall  provide  documentation  to  substantiate  any  field  test  claims  relative  to 
hardware  proposed. 

The  ticket  number  must  print  on  the  ticket  in  a  scannable  format  for  processing  through 
high-speed  TRP  devices. 

Ticket  paper  stock  must  be  highly  durable  such  that  the  OCR-A  scan  line  on  tickets 
produced  and  processed  through  the  US  Post  Office  (i.e.,  mailed  through  the  US  Post 
Office,  in  envelopes  approved  by  the  City  for  use  at  point  of  issuance,  and  received  at  the 
lockbox  processing  facility)  can  be  successfully  read  and  the  tickets  processed  through 
the  Vendor's  automatic  payment  processing  equipment  located  at  the  Vendor's  lockbox 
processing  facility  without  any  equipment  (payment  processing  equipment)  adjustment 
required.  The  Vendor  shall  submit  acceptance  testing  documentation  to  substantiate 
fulfillment  of  this  requirement. 

Ticket  numbers  shall  print  in  an  OCR-A  readable  and  landscape  format. 

The  Vendor's  hand-held  application  shall  accommodate  preprinted  and  free  form 
printing. 

The  hand-held  device  application  shall  generate  the  issuing  officer's  signature  or  like 
authentication  as  determined  by  the  City,  and  badge  number  on  each  ticket. 

A  group  mode  function  shall  be  provided  for  situations  in  which  automated  repetition  of 
data  for  multiple  violations  in  the  same  location  or  for  the  same  violation  can  hasten  the 
issuance  process. 

The  hand-held  device  application  shall  accommodate  incident  and  trouble  reporting,  in 
the  field,  such  as  broken  parking  meters,  missing  signs,  etc...  and  shall  accommodate  the 
daily  reporting  of  such  information. 

The  hand-held  device  application  shall  provide  the  ability  for  officers  to  record  drive-off 
violators. 

The  Vendor's  system  shall  provide  an  end  of  shift  summary  printable  by  each  officer  on 
such  officer's  hand-held  device,  and  shall  include  at  a  minimum  the  date  worked  and 
total  tickets  issued. 

The  Vendor's  hand-held  application  shall  accommodate  the  entry  of  both  private  and 
public  comments. 
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The  Vendor  shall  provide  written  revised  documentation  for  all  hardware  and  software 
updates  and  enhancements  including  changes  to  peripheral  equipment  and  supplies  (i.e., 
violation  code  and  amount  changes,  changes  to  batteries,  carrying  straps,  docking 
stations,  keypads,  etc.). 

The  Vendor's  base  station  application  shall  generate  confirmation  that  all  data 
transmitted  has  been  accounted  for  and  successfully  transferred  from  the  hand-held 
device  to  the  base  station(s)  after  each  transfer  action.  Exception  reports  must  be 
generated  and  correction  procedures  must  be  described. 

The  base  station  application  shall  accommodate  transfer  of  updated  files  and  software 
revisions  from  the  base  station  to  the  hand-helds. 

The  Vendor's  application  shall  accommodate  entry  at  the  base  station  of  data  from  hand 
written  tickets  and  data  entry  procedures  for  such  functionality  shall  be  provided  by  the 
Vendor. 

The  Vendor's  application  shall  accommodate  entry  at  the  base  station  of  officer  status 
information  for,  at  a  minimum,  officers  not  in  the  field. 

The  Vendor's  application  shall  generate  a  hand-held  inventory  tracking  log  which  tracks, 
at  a  minimum,  devices  in  use,  devices  sent  for  repair,  devices  lost,  devices  stolen,  and  the 
corresponding  date  of  each  event  and  return  to  service  or  replacement  date. 

The  Vendor's  application  shall  provide  for  easy  back  up  and  restoration  of  data  based  on 
user-defined  parameters. 

The  Vendor  shall  produce  on  a  daily  basis  a  transmission  report  to  substantiate  successful 
transmission  of  hand-held  data  to  the  Vendor's  core  parking  violation  system. 

The  Vendor's  application  shall  automatically  (unattended)  scan  for  the  presence  of  hand- 
held devices  placed  in  cradles  and  when  detected  automatically  upload  ticket  data  from 
the  hand-held  devices  to  the  base  station(s)  and  download  to  the  hand-held  devices  from 
the  base  station(s)  any  updated  information  or  updated  operational  software. 

(4.37.27)  Submission  of  Hardware  Proposed 

Prospective  Vendors  shall  be  required  to  submit  for  hardware  evaluation  purposes,  the 
hand-held  device(s)  as  proposed  in  response  to  the  City's  Parking  Violation  /  Parking 
Management  Information  Services  System  Request  for  Proposals  (PVPMISS  RFP). 
Proposers  may  propose  up  to  three  (3)  different  devices  and  shall  therefore  submit  one 
unit  for  each  hardware  platform  proposed. 

Such  device(s)  shall  be  plainly  packaged  and  labeled  with  identifying  Vendor 
information. 
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Such  device(s)  shall  be  the  exact  hardware  configuration  as  described  in  the  Vendor's 
proposal  and  shall  be  accompanied  by  the  manufacturer's  specifications.  Vendors  shall 
indicate  if  the  hardware  proposed  is  a  different  generation  (i.e.,  newer  or  older  model 
unit)  hardware  than  submitted  for  evaluation  purposes  and  clearly  note  any  device 
discrepancies  as  well  as  provide  an  explanation  for  the  submission  of  such  device(s). 

Vendors  shall  submit  operating  instructions  for  each  device. 

Such  device(s)  shall  be  accompanied  by  fully  functioning  batteries.  Vendor's  shall  note 
if  such  batteries  are  new  or  reconditioned. 

Such  device(s)  shall  be  accompanied  by  paper  such  that  sample  tickets  can  be  produced. 
The  Vendor  shall  note  if  such  paper  is  not  the  paper  proposed  in  the  Vendor's  proposal 
for  use  with  the  device  as  proposed  for  the  City. 

Such  device(s)  shall  contain  a  full  alphanumeric  keypad  with  at  least  forty  (40)  keys 
including  separate  alphabetic  (A-Z)  and  separate  numeric  (0-9)  characters  plus 
appropriate  function  keys  and  character  symbol  keys  such  that  license  plate  characters 
(i.e.,  asterisk,  plus  sign,  etc..)  can  be  easily  entered  with  minimal  multiple  or 
simultaneous  keystrokes  required. 

Such  device(s)  shall  be  accompanied  by  a  carrying  strap  or  case  to  facilitate  actual  field- 
testing  operability. 

The  Vendor  shall  note  if  the  device  is  designed  for  right  or  left  hand  use,  if  applicable. 

The  City  currently  utilizes  Politess  X600  devices,  manufactured  by  Schweers  Inc.  for  this 
application. 

The  hardware  proposed  for  this  application  shall  be  comparable  to  the  devices  currently 
in  production  in  terms  of  device  specifications  available  from  Schweers,  for  this  product 
and  in  terms  of  features,  functionality,  durability,  user-friendliness  and  docking 
procedures  for  upload  and  download  of  data  and  battery  charging. 

The  Vendor  may  provide  a  list  of  additional  hardware  that  is  capable  of  supporting  the 
Vendor's  hand  held  ticket  issuance  application,  if  applicable. 

(4.37.28)  Supervisory  Application  and  Capabilities 

The  Vendor  shall  provide  a  Supervisory  application  as  part  of  the  Vendors  Hand  Held 
Ticket  Issuance  application.  Such  Supervisory  application  shall  include  the  capability  for 
BTD  Enforcement  Supervisor  personnel  to  effectively  end  efficiently  monitor  and  track 
issuance  activity  and  data  for  officers  assigned  to  such  supervisors.  This  shall  include 
field  monitoring  of  ticket  issuance  activity  on  a  daily  basis  during  shifts  whereby  tickets 
may  be  issued  with  such  data  resident  on  the  Hand  Held  but  not  yet  updated  to  the  core 
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Parking  Violation  System.  Such  ticket  data  shall  be  transmitted,  preferably  wirelessly,  to 
a  supervisory  application  and  device  in  an  efficient  and  effective  manner  in  order  to 
provide  supervisor  personnel  with  real-time  ticket  issuance  activity.  The  Vendors 
Supervisory  application  shall  provide  the  capability  for  supervisors  to  view  ticket  data  in 
various  modes,  i.e.,  ticket  facsimile  view,  as  well  as  inspection  of  ticket  data  for  accuracy 
and  completeness.  The  Vendors  Supervisory  application  shall  include  the  capability  to 
record  and  log  supervisor  activity  for  subsequent  reporting  purposes,  in  terms  of,  for 
example,  how  many  tickets  supervisors  "check"  during  each  shift,  etc. . .  System  quality 
control  features  shall  be  provided  such  as  verification  of  Hand  Held  Ticket  Issuance 
application  system  edits  and  data  tables. 

Such  data  shall  be  viewable  on  a  portable  or  tablet/lap  top  device  via  a  viewing  screen  no 
less  than  8"xl0".  The  Vendor  shall  provide  a  minimum  of  thirty  (30)  such  devices. 
Printing  capability  shall  also  be  provided  in  an  optimally  efficient  and  effective  manner. 

The  Vendors  Supervisory  application  shall  include  the  capability  to  produce  activity 
reports  in  the  field  for  analysis  purposes.  Such  reports  shall  complement  activity  and 
analysis  reports  outlined  elsewhere  in  this  document.  Hardware  proposed  for  this 
application  shall  be  subject  to  the  performance  standards  described  elsewhere  in  this 
document.  The  Vendor  shall  be  responsible  for  installation  and  maintenance  of  any 
vehicle-mounting  devices  necessary  to  secure  units  in  mobile  patrol  vehicles  as  well  as 
any  vehicular  modifications  necessary  to  accommodate  the  efficient  and  effective 
operation  of  such  devices  and  application. 
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4.38 

DOCUMENT  IMAGE  PROCESSING  AND  WORKFLOW  SYSTEM 
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(4.38)  DOCUMENT  IMAGE  PROCESSING  AND  WORKFLOW  SYSTEM 

(4.38.0)  Document  Image  Processing  and  Workflow  System 

The  City  requires  a  document  image  processing  and  workflow  system  for  document 
storage  and  retrieval  and  workflow  management  (with  the  emphasis  on  workflow 
management).  This  document  image  processing  and  workflow  system  shall  be  fully 
integrated  with  all  systems  and  subsystems  of  the  Vendor's  PVPMISS. 


(4.38.1)  Document  Input  /  Scanning 

All  lockbox  received  parking  ticket  related  correspondence  will  be  imaged  at  the 
lockbox  processing  facility  by  the  Vendor.  The  Vendor's  scanning  device(s)  must 
accommodate  at  a  minimum,  correspondence  items  which  will  likely  contain  two  or 
more  pages  containing  typed,  machine  printed  or  handwritten  text  (frequently  two- 
sided),  of  various  sizes,  weights,  colors,  etc.,  as  well  as  photographs  or  drawings  which 
will  require  imaging.  The  envelopes  which  contain  correspondence  must  also  be 
imaged  in  order  to  capture  the  postmark  date  of  the  correspondence.  Correspondence  is 
also  frequently  enclosed  inside  actual  parking  tickets,  therefore,  some  parking  tickets 
received  at  the  lockbox  would  require  imaging.  Correspondence  received  via  internet 
(i.e.,  the  City's  or  an  approved  vendor's  website)  must  be  available  in  the  Document 
Image  Processing  &  Workflow  System. 

Additional  documents,  such  as  disposition  forms,  refund  forms,  and  correspondence 
received  at  City  Hall,  shall  be  imaged  by  the  City  at  the  City's  OPC  location. 

Note:  The  Vendor  shall  also  scan  original  "paper"  manually  issued  parking  tickets  such 
that  said  tickets  shall  be  available  via  the  Vendor's  Parking  Violation  System. 


(4.38.2)  Document  Batching 

Correspondence  received  and  imaged  at  the  lockbox  shall  be  batched  as  follows: 
correspondence  shall  be  opened,  batched  and  counted.  The  correspondence  is  separated 
into  batches  of  ^correspondence  received  in  the  parking  ticket  mailer  documents 
(tickets),  and  2)correspondence  from  all  other  documents  (other).  These  items  are  then 
counted  and  the  counts  reconciled  to  the  total  items  received. 

Documents  shall  then  be  grouped  into  batches  of  10  items  per  batch  with  Scanning 
Separator  Pages  between  each  item  within  each  batch.  (For  workflow  processing 
management,  correspondence  from  tickets  [tickets]  and  correspondence  from  other 
documents  [other]  shall  remain  separated  for  batch  scanning  purposes.  Therefore,  items 
scanned  as  'tickets'  shall  be  available  via  the  'ticket'  queue  and  items  scanned  as  'other' 
shall  be  available  via  the  'other'  queue.)  Each  batch  shall,  as  the  first  item  scanned, 
contain  a  Batch  Control  Sheet  indicating  the  scanning  location,  batch  date  (which  shall 
be  the  scan  date),  batch  count,  batch  number,  output  queue  and  person  performing 
scanning. 

It  shall  be  the  Vendor's  responsibility  to  verify  and  ensure  that  items  scanned  are 
scanned  properly  and  that  batch  update  count  and  information  matches  output/system 
update  information  when  the  scanning  process  is  completed.  The  Vendor  shall  maintain 
a  record  of  control  logs  and  make  such  logs  available  to  the  City.  It  shall  be  the 
Vendor's  responsibility  to  verify  and  ensure  that  each  page  scanned  is  legible  and 
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scanned  such  that  items  are,  for  example,  'right  side  up',  not  folded  or  otherwise 
distorted  in  the  scanning  process  or  as  a  result  of  the  scanning  process.  It  shall  be  the 
Vendor's  responsibility  to  verify  and  ensure  that  items  received  via  internet  are  properly 
available  with  all  required  information  in  the  Workflow  System. 

Correspondence  scanned  at  the  lockbox  or  received  via  internet  shall  be  available  to  the 
City  in  the  Vendor's  workflow  processing  system  the  same  day.  The  original 
correspondence  scanned  shall  be  forwarded  to  the  City  within  12  hours,  batched  as 
scanned.  Correspondence  received  at  the  lockbox  requiring  scanning  shall  be  scanned 
within  12  hours  of  receipt  of  such  correspondence  at  the  lockbox. 

The  Vendor  shall  have  the  capacity  to  process  at  a  minimum  300  -  500  documents  of 
correspondence  each  day;  each  piece  of  correspondence  consists  of  approximately  3-5 
pages. 

Correspondence  received  directly  at  OPC  shall  be  scanned  as  described  above  with  City 
staff  performing  batch  control  functions.  Correspondence  received  directly  at  OPC  that 
represents  additional  correspondence  for  existing  cases  shall  be  immediately  indexed  as 
part  of  the  scanning  process,  to  the  appropriate  ticket  or  tickets  and  added  to  an  existing 
case.  Correspondence  scanned  at  OPC  shall,  by  7:00  AM  of  the  following  workday,  be 
available  to  the  City  via  the  Vendor's  workflow  processing  system. 


(4.38.3)  Document  Storage  and  Workflow  Processing  System 

Correspondence  scanned  at  the  lockbox  or  received  via  internet  shall  be  available  to  the 
City  in  the  Vendor's  workflow  processing  system  the  same  day.  The  workflow 
processing  system  shall  assign  work  to  users  based  on  processing  requirements  and 
priorities  established  by  City  OPC  supervisors  and  managers. 

OPC  staff  will  process  correspondence  via  access  to  predetermined  input  queues.  For 
example,  some  staff  shall  have  access  to  the  'ticket'  queue  which  will  contain  lockbox 
scanned  or  OPC  scanned  correspondence  from  tickets,  but  may  not  have  access  to  the 
'other'  queue  which  will  contain  lockbox,  OPC  scanned,  or  internet  correspondence 
from  other  mail.  OPC  staff  will  then  read  the  electronic  image  of  the  correspondence, 
index  it  to  the  appropriate  ticket  or  tickets  creating  a  case,  update  the  name  and  address 
if  necessary  (name  and  address  shall  automatically  default  to  the  PVPMISS  name  and 
address  unless  updated  by  the  user),  determine  what  actions  or  what  claims  processing 
correspondence,  suspend  or  disposition  code  should  be  assigned  to  the  case,  and 
automatically  as  a  result  of  the  code  entered,  move  the  case  to  a  post  processing  queue. 
As  part  of  this  workflow  processing  system,  the  Vendor  shall  provide  the  capability  to 
simultaneously  access  and  view  all  PVPMISS  systems  and  subsystems,  on-line,  real- 
time via  a  user-friendly  operationally  efficient  and  effective  manner.  Further,  such 
access  shall  be  fully  integrated  between  the  workflow  processing  system  and  all 
PVPMISS  systems  and  subsystems  such  that  the  imaged  documents  can  be  accessed 
and  updated  at  the  parking  ticket  level  on  the  PVPMISS  by  general  system  users. 
Updates  performed  to  the  parking  ticket  via  the  workflow  processing  system  shall  be 
reflected  at  the  parking  ticket  level  on  the  PVPMISS  the  same  day. 


(4.38.3.1)  Screen  Capture  Capability 

The  Vendor  shall  provide  the  capability  to  capture  PVPMISS  system  and  subsystem 
(including  MASS  RMV  UMS  database  data)  screen  data  to  a  workflow  processing 
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system  imaged  case  and  retain  this  data  as  an  'imaged'  document.  Normally,  three  to 
four  PVPMISS  screens  will  be  captured  for  each  case. 


(4.38.4)  Correspondence  Processing  Queues 

Correspondence  scanned  at  the  lockbox  or  received  via  the  internet  and  at  OPC  shall  be 
available  for  processing  in  workflow  queues  determined  as  a  component  of  the  batch 
set-up  process.  For  example,  correspondence  received  in  the  ticket  mailers  shall  be 
scanned  to  the  'ticket'  queue,  correspondence  received  in  any  other  envelope  shall  be 
scanned  to  the  'other'  queue,  and  correspondence  may  also  be  scanned  to  any  other 
valid  output  queue  specified. 

The  Vendor's  correspondence  workflow  processing  system  shall  provide  access  to 
imaged  documents  via  batch,  which  would  contain  entire  batches  of  documents,  or  via 
individual  ticket. 

The  Vendor's  workflow  processing  system  shall  provide  the  capability  for  City  staff  to 
fully  process  the  correspondence  and,  via  the  workflow  system,  update  the  PVPMISS 
ticket  record  with  the  appropriate  correspondence  processing  suspend  or  disposition 
code.  Upon  entry  of  the  correspondence  processing  suspend  or  disposition  code,  the 
'imaging  case'  shall  be  routed  to  the  appropriate  post  processing  output  queue  such  that 
the  'imaging  case'  is  available  via  that  output  queue.  This  action  of  rerouting  the 
imaged  case  to  the  post  processing  output  queue  shall  be  accomplished  as  a  fully 
automated  component  of  the  disposition  or  suspend  correspondence  processing  code 
entry.  For  example,  entry  of  a  disposition  code  of  72  which  schedules  a  ticket  for 
dismissal,  shall  automatically  and  without  additional  screen  toggle  or  keystrokes,  route 
the  case  to  the  post  processing  dismiss  review  queue.  Subsequently,  a  supervisor  shall 
have  access  to  the  dismiss  review  queue  which  shall  contain  the  code  72  case,  and  may 
then  approve  the  dismissal  action,  deny  the  dismissal  action  or  otherwise  recode  (and 
hence  reroute)  the  72  case. 

The  Vendor's  workflow  processing  system  shall  provide  access  to  rerouted 
correspondence  in  the  appropriate  post  processing  output  queues  the  same  day 
following  initial  processing. 

The  Vendor's  correspondence  workflow  processing  system  shall  provide  the  capability 
to,  based  on  City  processing  code-specific  guidelines,  record  correspondence 
disposition  or  suspend  processing  codes  in  the  workflow  system  without  performing  the 
appropriate  PVPMISS  code-specific  action  until  the  ticket  is  subsequently  updated  with 
such  disposition  code(s)  from  a  post  processing  review  queue.  For  example,  in  the  case 
of  the  code  72  dismissal  above,  the  initial  processing  and  workflow  entry  of  the  code  72 
would  not  cause  a  PVPMISS  update  of  the  ticket  to  a  dismissal  until  approved  by  the 
supervisor  via  the  post  processing  dismiss  review  queue.  Other,  more  general 
correspondence  suspend  codes  would,  however,  produce  a  PVPMISS  code-specific 
action  upon  initial  workflow  entry.  An  example  of  such  a  code  would  be  a  code  35 
denial  which  would  initiate  a  letter  to  the  registrant  indicating  that  the  City  is  unable  to 
dismiss  the  ticket  in  question. 
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The  Vendor's  workflow  processing  system  shall,  in  a  fully  automated  manner  and 
without  additional  screen  toggle  or  keystrokes,  reflect  all  workflow  entered  suspend  or 
disposition  correspondence  processing  codes  at  the  ticket  level  in  all  PVPMISS  systems 
and  subsystems  in  accordance  with  City  processing  guidelines.  Such  data  shall  be 
updated  by  7:00  AM  of  the  next  workday  following  initial  processing  (i.e.,  codes  data 
entered  on  Monday  shall  be  reflected  in  the  Vendor's  PVPMISS  systems  and 
subsystems  by  7:00  AM  Tuesday).  This  PVPMISS  systems  and  subsystems  update 
shall,  in  a  fully  automated  manner  and  without  additional  screen  toggle  or  keystrokes, 
produce  the  code  appropriate  suspend  or  disposition  correspondence  processing  system 
action  (i.e.,  dismiss  a  ticket,  send  a  correspondence  letter,  suspend  and  place  a  ticket  on 
hold,  etc.). 


(4.38.4.1)  Correction  Capability 

The  Vendor's  workflow  processing  system  shall  provide  the  capability  for  authorized 
supervisory  City  staff  to  perform  corrections  to  workflow  entered  correspondence 
processing  codes  such  that  corrections  performed  on  the  same  workday  as  the  initial 
processing  shall  be  updated  to  the  workflow  processing  system  and  all  PVPMISS 
systems  and  subsystems.  All  corrections  entered  in  this  manner  shall  'overlay'  and 
'back-out'  any  previous  action  and  all  processing  activities  described  in  this  document 
shall  occur  based  on  the  corrected  processing  code(s). 


(4.38.5)  Hearing  Processing 

The  Vendor's  workflow  processing  system  shall  provide  the  capability  for  City  staff  to 
schedule,  conduct  and  review  parking  ticket  hearings  on  one  or  multiple  tickets.  This 
capability  shall  be  provided  for  both  scheduled  and  unscheduled/walk-in  hearings.  The 
Vendor's  workflow  hearing  processing  system  shall  provide  the  capability  for  City  staff 
to  view  all  images  associated  with  a  hearing  case,  capture  PVPMISS  system  and 
subsystem  screen  data,  update  registrant  name  and  address  data,  record  a  disposition 
code  for  each  ticket  involved,  record  comments,  print  a  disposition/voucher  (hearing 
outcome)  form,  and  route  the  entire  hearing  case  to  the  supervisory  review  queue.  The 
results  of  the  hearing  shall  be  reflected  at  the  ticket  level  in  the  Vendor's  PVPMISS 
systems  and  subsystems  only  after  being  processed  in  the  supervisory  hearing  review 
queue;  this  review  will  either  approve  the  hearing  code(s)  entered  or  deny  the  hearing 
code(s)  entered.  The  Vendor's  PVPMISS  systems  and  subsystems  update  shall,  in  a 
fully  automated  manner  and  without  additional  screen  toggle  or  keystrokes,  produce  the 
appropriate  suspend  or  disposition  hearing  action  and  reflect  such  data  by  7:00  AM  of 
the  next  workday  following  supervisor  data  entry  via  workflow  of  the  hearing  code. 


90 


(4.38.6)     Tickets  Not-On  -Line 


(4.38.6.1)  Workflow  Correspondence  Processing 

The  Vendor's  workflow  correspondence  processing  system  shall  provide  the  capability 
to  process  correspondence  related  to  parking  tickets  not  yet  available  in  the  Vendor's 
PVPMISS  (such  tickets  are  tickets  which  have  not  yet  been  submitted  by  the  issuing 
agencies  for  data  entry  to  the  PVPMISS).  The  Vendor's  workflow  correspondence 
processing  system  shall  provide  the  capability  for  City  staff  to,  via  the  workflow 
processing  system,  enter  ticket  number  and  amount  due,  index  the  correspondence, 
process  the  correspondence  to  the  extent  possible  as  described  earlier  in  this  document 
via  entry  of  a  correspondence  or  disposition  suspend  code,  and  route  the  imaged  case  to 
a  'holding  queue'  whereby  NO  PVPMISS  ACTION  on  the  ticket  would  take  place. 
The  Vendor's  correspondence  workflow  system  shall,  within  24  hours  of  data  entry  and 
update  of  the  ticket  to  the  PVPMISS  (i.e..  after  the  ticket  is  turned-in  by  the  issuing 
agency  and  updated  to  the  PVPMISS),  in  a  fully  automated  manner  and  wholly  without 
City  staff  involvement,  route  the  imaged  case  to  the  'Now-On-Line'  queue.  All  images 
associated  with  each  ticket  in  such  cases  shall  be  available  via  the  imaged  case  in  the 
'Now-On-Line'  queue.  The  workflow  processing  system  shall  display  the 
correspondence  disposition  or  suspend  code  initially  entered  and  provide  the  capability 
for  City  staff  to  process  the  correspondence  as  described  earlier  in  this  document  and  to 
change  or  apply  such  code(s). 

The  Vendor's  workflow  processing  system  shall,  in  a  fully  automated  manner  and 
without  additional  screen  toggle  or  keystrokes,  reflect  all  workflow  entered  suspend  or 
disposition  correspondence  codes  at  the  ticket  level  in  all  PVPMISS  systems  and 
subsystems  in  accordance  with  processing  guidelines  established  by  the  City.  Such  data 
shall  be  updated  by  7:00  AM  of  the  next  workday  following  processing  (i.e.,  items 
entered  on  Monday  shall  be  updated  by  7:00  AM  Tuesday). 


(4.38.6.2)  Workflow  Hearing  Processing 

The  Vendor's  workflow  hearing  processing  system  shall  provide  the  capability  for  City 
staff  to  conduct  and  review  walk-in  hearings  for  tickets  not  yet  available  in  the 
Vendor's  PVPMISS  (such  tickets  are  tickets  which  have  not  yet  been  submitted  by  the 
issuing  agencies  for  data  entry  to  the  PVPMISS).  The  Vendor's  workflow  hearing 
processing  system  shall  provide  the  capability  for  City  staff,  via  the  workflow  system, 
to  enter  ticket  number  and  amount  due  and  conduct  the  hearing  as  previously  described 
in  this  document. 
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(4.38.7)  Scanning  Additional  Documents  to  Existing  Cases 


The  Vendor's  scanning  processing  system  shall  provide  the  capability  for  City  staff 
located  at  City  Hall  to  scan  correspondence  documents  to  pre-indexed  existing  image 
cases.  Such  documents  may,  for  example,  include  evidence  presented  at  hearings  or 
documents  requested  by  City  staff  to  complete  processing  of  disposition  transactions, 
such  as  vehicle  repair  receipts  to  substantiate  disabled  vehicle  claims.  Documents 
scanned  through  this  Scan  Additional  process  shall  be  available  as  imaged  documents  in 
the  preexisting  image  case(s)  by  7:00  AM  of  the  next  workday  following  scanning  (i.e., 
items  scanned  Monday  shall  be  available  in  the  document  image  processing  and 
workflow  system  by  7:00  AM  Tuesday).  Such  scanning  shall  include  color  and  duplex 
images. 


(4.38.8)  User-Friendly  Operationally  Efficient  and  Effective  System 

The  City  requires  that  the  Vendor's  Document  Image  Processing  and  Correspondence 
Workflow  System  be  user-friendly  and  operationally  efficient  and  effective.  Processing 
buttons,  keystrokes  and  screen  toggle  must  be  kept  to  a  minimum.  Screen  refresh  rates 
must  be  optimized  and  layouts  and  menus  must  be  user-friendly.  For  example, 
selection  of  a  disposition  button  shall  display  a  menu  of  available  disposition  codes  in 
numerical  order  with  brief  text  descriptions.  Further,  selection  of  a  particular 
disposition  code  shall  display  a  confirmation  of  such  selection  as  well  as  the  appropriate 
post  processing  output  queue  for  the  code  selected.  Application  of  the  selected  code 
shall  automatically  and  without  additional  screen  toggle  or  keystrokes,  cause  the  next 
item  in  the  queue  being  processed  (worked)  to  be  displayed.  When  all  items  in  the 
queue  have  been  processed,  the  system  shall  display  this  message  to  the  user.  Also,  the 
Vendor's  workflow  system  shall  provide  the  capability  for  City  staff  to  view  a  list  of 
documents  /  tickets  in  each  queue  and  to  select  a  case  to  view  and  process.  Imaged 
documents  must  be  displayed  in  a  user-friendly,  operationally  convenient,  efficient  and 
effective  manner.  OPC  staff  must,  with  no  or  minimal  document  manipulation,  be  able 
to  read  the  electronic  image  of  the  document  on  imaging  specific  (21"  or  larger  viewing 
area)  monitors.  OPC  staff  must  have  the  capability  to  manipulate  imaged  documents  in 
terms  of  size  and  position  and  be  able  to  scroll  or  otherwise  easily  move  or  view 
multiple  or  different  pages  contained  in  one  imaged  correspondence  record.  OPC  staff 
must  have  the  capability  to  view  PVPMISS  systems  and  subsystems  simultaneously 
with  imaged  documents  and  workflow  processing  instructions. 


(4.38.9)  Multiple  PVPMISS  Sessions 

The  Vendor  shall  provide  access  to,  display  of  and  screen  capture  of,  at  a  minimum  two 
simultaneous  PVPMISS  sessions;  one  of  which  shall  be  for  access  to  the  Massachusetts 
RMV  UMS  database  and  the  other(s)  of  which  shall  be  for  access  to  the  Vendor's 
PVPMISS  systems  and  subsystems  (i.e.,  general  processing). 
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(4.38.10)  System  Security  /  User  Access 


As  discussed  elsewhere  in  this  document,  system  access  and  processing  capability  shall 
be  provided  via  City  defined  user  profiles.  For  example,  the  City  may  require  that  some 
users  receive  access  to  only  certain  input  and  output  queues.  The  Vendor's  document 
image  workflow  processing  system  shall  provide  user-friendly,  operationally  efficient 
and  effective  system  access.  The  Vendor's  workflow  processing  system  shall  provide 
the  capability  to  easily  modify  user  profiles  and  to  add  and  delete  users  according  to 
City  specifications. 


(4.38.11)  Reports 

The  Vendor  shall  provide  all  management  and  operational  reports  required  by  the  City. 


(4.38.12)  Equipment.  Service  and  Communication 

The  Vendor  shall  be  responsible  for  all  hardware  devices  (i.e.,  file  servers,  tape  drives, 
gateways,  jukeboxes,  scanners,  hubs,  routers  and  DSU's)  regardless  of  location  (Vendor 
or  City  Sites),  including  installation  and  maintenance,  all  software  including  workflow 
management  applications,  all  interface  applications  to  the  Vendor's  systems  and 
subsystems  and  all  communications  networks  necessary  to  meet  the  City's  requirements 
relative  to  document  image  processing.  Additional  PVPMISS  network  capability  and 
other  equipment,  service  and  supply  requirements  are  described  in  Section  4.21  of  this 
RFP. 


(4.38.13)  System  Uniformity 

The  Vendor's  workflow  processing  system  shall  be  standardized  for  all  system  users 
such  that  the  identical  system  software  for  all  components  of  the  Vendor's  system(s)  is 
utilized  by  all  system  users.  Following  adequate  system  testing,  system  and  software 
enhancements  shall  be  uniformly  introduced  to  all  system  users. 


(4.38.14)  Code  35  Response  via  Web 

Code  35  notices  are  sent  to  customers  who  have  disputed  tickets,  which  the  City  has 
determined,  cannot  be  administratively  dismissed. 

The  Vendor  will  provide  a  link  between  workflow  and  the  Web,  giving  the  customer  an 
option  of  updating  a  code  35  notice  to  a  code  20  notice  (Scheduled  Hearing),  or  making 
payment  via  the  Web.  All  35  notices  being  updated  to  a  20  must  generate  a  response 
via  e-mail  confirming  a  hearing  request  received  and  giving  the  customer  a  date  and 
time  of  their  scheduled  hearing. 

All  data  must  generate  reports  for  supervisory  review. 
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(4.38.15)  Data  Adjustments  /  System  Problems 


The  Vendor's  imaging  system  will  have  the  capability  of  processing  Data 
Adjustments/System  Problems  through  a  connection  with  the  Vendor's  core  parking 
violation  system. 

Data  Adjustments  are  scanned  correspondence  received  at  the  City  concerning  parking 
ticket  errors.  There  are  three  main  categories  of  adjustments.  Ticket  errors  (Wrong 
plate  #,  Zone  adjustment,  etc.),  Payment  reapplication  (Payment  applied  to  incorrect 
violation)  and  Incorrect  Owner  (Wrong  registrant  name/address).  Each  category  of 
adjustment  shall  have  a  distinct  designated  code  in  the  Vendor's  core  parking  violation 
system. 

A  correspondence  staff  member  will  choose  the  type  of  adjustment  to  be  done,  from  the 
categories  listed  above  (via  a  drop  down  box).  He/she  will  route  all  scanned 
documentation  for  a  particular  piece  of  correspondence,  as  well  as,  all  parking  violation 
system  and  RMV  system  screen  scraped  data  and  any  additional  scanned  images  they 
may  need  to  add  to  the  workflow  queue  designated  for  this  purpose. 

A  supervisor  will  review  the  documentation  and  perform  the  adjustment  in  the  vendor's 
core  parking  violation  system.  All  records  and  images  are  then  sent  to  a  Done  Queue, 
to  be  retained  for  immediate  access  for  a  period  of  ninety  days. 


(4.38.16)  A-9  Letters  in  Workflow 

The  Vendor's  imaging  system  shall  provide  the  capability  for  correspondence  staff  to 
process  A-9  transactions  from  workflow. 

So-called  "A-9  transactions"  are  letters  sent  to  customers  requesting  additional 
information  be  forwarded  to  the  City  for  the  purpose  of  resolving  ticket  disputes. 

A  correspondence  staff  member  will  process  these  "  A-9  transactions"  from  workflow 
and  route  original  correspondence,  along  with  the  proposed  A-9  transaction  letter  to  a 
supervisor  for  review  and  release.  The  supervisor  will  retrieve  the  correspondence  from 
the  review  queue  and  approve  the  letter  to  be  sent.  This  will  initiate  an  update  in  the 
Vendor's  core  system  based  on  a  system  code. 

A-9  transactions  processed  via  workflow  in  the  Vendor's  core  system  would  generate 
case  numbers  for  reference  purposes.  All  case  numbers  would  be  available  for  review. 


(4.38.17)  Resident  Permit  Renewals  via  Workflow 

The  Vendor's  imaging  system  shall  provide  the  capability  for  correspondence  staff  to 
process  Resident  Permit  Renewals  via  workflow. 

Resident  Permit  Renewal  applications  are  sent  to  valid  permit  holders,  currently  every 
two  years.  Residents  may  submit  applications  via  mail,  received  at  the  Vendor's 
lockbox  facility,  City  Hall  or  via  internet.  Applications  received  via  the  Vendor's 
lockbox  shall  be  scanned  according  to  the  scanning  requirements  set  forth  in  this 
document,  and  shall  be  made  available  to  the  City  via  a  specified  processing  queue  in 
the  Vendor's  Document  Image  Processing  &  Workflow  System.  A  correspondence  or 
Resident  Permit  Division  staff  member  will  process  Resident  Permit  Renewals  from 
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workflow  via  the  Resident  Permit  Parking  System.  Applications  which  are  not 
approved  shall  be  processed  in  accordance  with  the  specifications  set  forth  in  the 
Resident  Permit  Parking  System  and  initiate  generation  of  correspondence  to  such 
customers. 

Resident  Permit  Renewal  applications  received  via  internet  shall  be  made  available  to 
the  City  for  processing  via  the  Vendor's  Document  Image  Processing  &  Workflow 
System  as  outlined  above. 
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4.39 


PRINTING  OF  PARKING  VIOLATION  TICKETS. 
DUNNING  NOTICES  AND  OTHER  ITEMS  AND 
THE  PROVISION  OF  ON-GOING  SUPPORT  SERVICES 
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(4.39)       PRINTING  OF  PARKING  VIOLATION  TICKETS.  DUNNING 
NOTICES  AND  OTHER  ITEMS  AND  THE 
PROVISION  OF  ON-GOING  SUPPORT  SERVICES 


(4.39.0)  Introduction 

This  section  of  the  RFP  covers  printed  items  that  will  be  utilized  by  the  PVPMISS 
Vendor,  the  City  and  the  public  during  the  course  of  the  contract  to  be  entered  into 
pursuant  to  this  RFP.  Prior  to  this  RFP,  these  items  were  procured  via  a  separate 
contract.  For  this  RFP  these  printed  items  shall  be  incorporated  into  the  actual 
PVPMISS  contract.  Printed  materials  that  will  be  utilized  by  the  PVPMISS  vendor, 
independent  of  the  materials  specified  herein,  shall  be  the  direct  responsibility  of  the 
selected  proposer.  A  complete  list  of  current  tickets,  forms  and  other  items  and  their 
anticipated  annual  volume  has  been  provided  in  conjunction  with  this  RFP. 

The  responsibilities  set  forth  in  this  section  also  include  printing  and  forms 
consulting,  inventory,  warehousing,  shipping  and  composition. 

The  enforcement  of  parking  regulations  is  an  extremely  sensitive  matter  to  the  City  of 
Boston.  Parking  tickets,  forms  and  other  printed  items  issued  to,  mailed  to,  or 
otherwise  used  by  the  public,  by  BTD/OPC,  and  by  the  primary  PVPMISS  vendor 
must  be  accurate  and  of  high  quality.  Any  deficiencies  can  have  serious  negative 
implications  for  the  public,  the  City  and  for  the  primary  PVPMISS  vendor. 

Specifications  and  volumes  of  all  printed  materials  will  be  contained  in  the  Appendix 
of  this  RFP. 

If  the  prime  vendor  utilizes  a  printing  subcontractor  that  subcontractor  will  be 
identified  with  a  detailed  explanation  of  that  contractor's  experience  in  printing  Hand 
Written  Parking  tickets  and  the  other  items.  A  minimum  of  five  (5)  years  of  printing 
the  required  items  is  necessitated. 

Any  errors  in  tickets  or  processing  errors  and  problems  due  to  ticket  printing  and 
construction  may  result  in  the  immediate  termination  of  these  services  as  provided  by 
the  prime  vendor  or  the  prime  vendor's  printing  subcontractor. 

Samples  of  the  two  versions  of  the  handwritten  parking  tickets  and  all  envelopes  and 
forms  will  be  distributed  at  the  Mandatory  Proposers  Conference. 

(4.39.1)  Critical  Nature  of  Hand  Written  Parking  Tickets 

Accurate,  high  quality  hand  written  parking  tickets  are  critical  to  the  operations  of 
BTD/OPC.  Currently  approximately  90%  of  the  parking  tickets  issued  by  the  City  of 
Boston  are  generated  from  the  Hand-Held  ticket  writing  devices.  Thus,  an  estimated 
10%  of  the  tickets  will  continue  to  be  hand  written  by  Boston  Police,  other  agencies 
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and  some  BTD  employees.  These  handwritten  tickets  will  continue  to  be  an  integral 
component  in  the  City's  overall  transportation  management  initiative.  Parking 
tickets  serve  as  the  primary  means  of  notification  to  motorists  of  a  parking  violation, 
providing  important  information  regarding  the  violation,  payment  and  appeal 
procedures. 

It  is  essential  that  each  parking  ticket  be  correctly  numbered  and  constructed  exactly 
according  to  the  specifications  contained  herein,  completely  free  of  defects. 
Duplicate  or  otherwise  incorrect  ticket  numbers  pose  serious  problems  for  the  data 
processing  system,  the  BTD/OPC  and  the  public  and  will  not  be  accepted. 
Overlapping,  duplicate  or  incorrect  ticket  numbers  directly  impact  the  ticket 
processing  and  violator  notification  programs  and  severely  compromise  the 
credibility  and  integrity  of  the  parking  enforcement  program. 

Hand  Written  tickets  must  meet  the  following  functional  requirements: 

a)  Tickets  must  be  "weather  proof"  and  durable  in  extremes  of  temperature 
and  precipitation.  As  they  are  placed  and  remain  on  vehicle  windshields 
for  extended  periods  of  time  and  are  issued/filled  out  in  the  same  extreme 
conditions. 

b)  Tickets  must  be  able  to  withstand  handling  by  the  recipient  and  the  U.S. 
Postal  service,  as  tickets  are  used  to  insert  payments  (usually  checks  and 
money  orders)  or  correspondence  and  sent  through  the  mail.  The 
self-mailer  must  not  become  separated  during  the  mailing  and  mail 
handling  process. 

c)  Tickets  must  be  easily  opened  in  such  a  way  that  the  ticket  number  and 
essential  data,  as  defined  by  BTD/OPC,  are  not  damaged  and  the  contents 
of  the  ticket  envelope  remain  intact. 

d)  Tickets  must  be  processable  by  sophisticated  and  sensitive  optical 
scanning  machinery  after  opening  with  limited  human  intervention.  The 
part  of  the  ticket  that  is  processed  through  the  scanning  machinery  must 
not  cause  the  machine  to  jam  or  suffer  any  other  operational  difficulties. 

Variations  of  any  kind  from  the  approved  specifications  in  the  color,  shape,  size, 
weight,  or  construction  will  not  be  accepted.  A  defective  ticket  or  a  variation  of  any 
ticket  of  any  one  specification  may  cause  the  entire  production  run  in  which  the 
defective  ticket  is  contained  be  rejected  at  the  vendor's  expense.  Printer  caused  errors 
with  the  parking  tickets  cannot  and  will  not  be  tolerated  and  therefore  must  be 
avoided. 
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(4.39.2)  Responsibility  for  Pre-Existing  Inventory 

At  the  start  of  the  contract,  July  1,  2010,  pre-existing  inventory  levels  should  be 
approximately  four  to  five  months  of  stock  for  all  items.  The  successful  proposer 
shall  assume  all  inventory  responsibilities  (and  costs)  for  this  material.  The 
successful  proposer  will  assume  any  cost  of  transporting  this  material  to  the 
successful  proposer's  warehouse  site  identified  in  their  proposal. 
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4.40 

TRAFFIC  MANAGEMENT  PERMITTING  SYSTEM 
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(4.40)  TRAFFIC  MANAGEMENT  PERMITTING  SYSTEM 


(4.40.0)  Traffic  Management  Permitting  Program 

The  City  of  Boston  Transportation  Department  (BTD)  is  responsible  for  the  issuance  of 
construction,  street  occupancy,  special  event  (i.e.,  parade)  and  valet  permits. 
Administration  of  this  program  is  currently  provided  by  the  Traffic  Management  Division 
of  the  BTD  located  at  various  locations  in  City  Hall.  Fees  are  charged  for  permits  in  this 
program. 

(4.40.1)  Traffic  Management  Permitting  System 

The  Vendor  shall  provide  a  Traffic  Management  Permitting  System  (TMPS)  for  the 
Traffic  Management  Division  of  the  BTD.  The  requirements  for  this  system  shall 
include,  but  are  not  necessarily  limited  to,  the  capability  to: 

allow  real-time  data  entry  and  printing  of  permits 

provide  for  the  data  entry,  tracking  and  response  to  complaints 

provide  for  the  data  entry  and  tracking  of  accounts  receivables  including 
delinquent  accounts 

provide  for  the  data  entry  and  tracking  of  warning  tickets 

provide  for  the  automatic  system  generated  work  orders  for  sign  and  meter 
changes 

provide  for  the  recording  of  temporary  regulation  changes 

allow  other  units  within  and  outside  BTD  access  to  TMPS  information 

permits  shall  print  at  a  location  specified  by  the  City  which  may  be  a  location 
other  than  the  primary  user  data  entry  site.  Re-print  capability  shall  be  provided 
in  a  user  friendly  operationally  efficient  manner. 

(4.40.2)  Permit  Issuance  and  Related  Forms 

The  Vendor's  TMPS  shall  provide  for  the  on-line,  real-time  issuance,  printing  and 
tracking  of  permits  and  associated  forms.  The  data  entry  screen  utilized  to  record  permit 
information  shall  closely  resemble  printed  forms.  The  Vendor's  TMPS  shall  provide  data 
entry  via  the  following: 
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data  entry  of  new  permits 

update  of  existing  permits  (revise/renew/cancel) 

copy  existing  permit  data  to  new  permits 

export  certain  permit  data  to  a  City  maintained  and  provided  label  printing 
application 

(4.40.3)  System  Components 

The  on-line  TMPS  must  accommodate,  at  a  minimum,  7,000  to  10,000  construction  and 
street  occupancy  permit  files  per  year,  mailing  of  4,000  to  5,000  invoices  and  notices  per 
year,  200  to  300  special  event  permits  per  year,  approximately  1,000  warning  tickets  per 
year  and  200  to  300  valet  permits  per  year. 

The  system  must  allow  access  via  location,  firm  name,  permit  number,  date,  district  and 
valet  operator  (for  valet  permits  only)  for  each  distinct  type  of  permit.  Each  permit  file 
may  include,  based  on  type  of  permit,  at  a  minimum,  the  following  information: 

firm  name,  and  related  data 

a  system  assigned  permit  number;  this  shall  be  a  unique  number,  with  the  first  two 
digits  being  year,  the  next  five  digits  being  permit  number  and  the  last  character 
being  a  revision/renewal  number 

location  of  permit  including  district 

description  of  the  work  to  be  performed  via  a  drop-down  list  /  table  file  of 
standard  descriptions;  a  comments  field  shall  be  provided  to  record  any  special 
requirements 

police  detail  requirements 

signage  requirements 

meter  occupancy  data 

materials  replacement  data 

expiration  date  of  permit 

authorization  code  for  staff  person  authorizing  permit 
operator  identification  code 
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permit  effective  date 


temporary  regulation  change  (temporary  vote) 

for  valet  permits  only,  the  following:  off-street  parking  facility  location,  linear 
feet  of  valet  zone  and  signage  data,  valet  company  and  a  scanning  feature  for 
inputting  application  forms,  maps,  correspondence,  etc. 

(4.40.4)  System  Fast  Paths 

Firm  information  (name,  address,  etc.)  shall  be  maintained  in  a  separate  look-up  table 
file  (listing).  Each  firm  shall  be  assigned  a  unique  account  number.  The  Vendor's  TMPS 
shall  provide  the  capability  for  City  staff  to  access  this  listing  from  the  permit  data  entry 
screen,  via  a  user-friendly  'fast-path'  and  to  capture  such  information  in  new  or  existing 
permit  records. 

The  Vendor's  TMPS  shall  provide  a  variety  of  user-friendly  'fast-paths'  via  drop  down 
lists  or  tables  from  main  data  entry  screen  fields  to,  for  example  and  as  required  for  each 
permit,  record  and  print  billing  data,  record  and  print  police  detail  information,  to  record 
and  print  materials  replacement  costs,  to  record  and  print  temporary  regulation  changes 
(temporary  votes),  etc. 

The  Vendor's  TMPS  shall  provide  for  the  automatic  generation  and  printing  of  sign  work 
orders  when  signage  change  requirements  are  specified  upon  permit  issuance. 

(4.40.5)  Collection  Activities 

The  Vendor's  TMPS  shall  provide  an  accounts  receivable  file  to  provide  invoicing, 
noticing,  payment  posting  and  collection  of  past  due  accounts. 

(4.40.5.1)       Invoicing  and  Noticing 

Invoicing  and  noticing  shall  include  the  following  for  each  permit: 

maintain  a  record  of  invoicing  activity  to  the  accounts  receivable  file 
print  invoices  with  required  control  reports 

track  receivables  by  permit  holder  including  current  and  aged  accounts 
receivables 

perform  interest  calculations 
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print  overdue  /  delinquent  dunning  notices 
provide  real-time  printing  of  billing  forms 


(4.40.5.2)  Payment  Posting 

Payment  posting  shall  include  the  following  for  each  permit: 
post  payments  for  invoices 
update  outstanding  balances  to  reflect  payments 
print  and  view  on-screen  payment  posting  journals 

(4.40.5.3)  Collection  of  Past  Due  Accounts 

The  Vendor's  TMPS  shall  provide  the  capability  to  maintain  a  file  of  all  past  due 
accounts  including  a  record  of  dunning  notice  activity  and  communications  with  permit 
holders. 


(4.40.5.4)  Complaint  Tracking 

The  Vendor's  TMPS  shall  provide  the  capability  to  maintain  a  record  of  complaints 
relative  to  valet  parking  permits.  This  may  include  the  capability  to  record  and  print 
complaint  response  and  administrative  review  outcome  records. 

(4.40.6)  Reporting  Requirements 

The  Vendor's  TMPS  shall  provide  all  management,  control,  audit  and  activity  reports 
required  by  the  City.  This  may  include  listings  of  special  events  by  district  and  street;  by 
special  issuance  requirements;  by  signage  required;  by  sign  work  orders;  by  type  of 
permit  issued,  renewed,  revoked  or  expired  by  firm  name,  location  or  date;  or  by  valet 
company. 

(4.40.7)  Additional  Requirements 

The  Vendor  shall  be  responsible  for  providing  file  back-up  procedures  for  all  TMPS  data. 
The  Vendor  shall  provide  file  archive  of  permit  data  according  to  date  specific  criteria. 


108 


The  Vendor's  TMPS  shall  provide  multi-level  password  specific  system  access  based  on 
City  specified  user  profiles. 
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SECTION  5.0 

METHODOLOGY  FOR  DETERMINING  THE  MOST 
ADVANTAGEOUS  PROPOSAL 
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SECTION  5.0 
METHODOLOGY  FOR  DETERMINING  THE  MOST 


ADVANTAGEOUS  PROPOSAL 


(5.1)  Introduction 

This  section  provides  a  discussion  of  the  steps  that  will  be  used  to  evaluate  the 
proposals,  determine  the  most  advantageous  proposal  and  select  a  contractor.  These 
steps  include  the  application  of  minimum  and  comparative  criteria,  assignment  of  a 
composite  rating,  and  the  selection  of  the  most  advantageous  proposal. 


(5.2)  Screening  the  Proposals  for  Responsiveness  and  Responsibility 

After  opening  the  technical  (non-price)  proposals,  the  City  will  examine  each  proposal 
to  determine  whether  it  meets  all  of  the  proposal  submission  requirements  and 
minimum  criteria  specified  in  the  RFP.  Any  proposer  who  fails  to  meet  any  of  the 
standards  set  forth  as  minimum  criteria  is  non-responsible  and  will  be  eliminated  from 
further  consideration. 

In  determining  the  responsiveness  of  a  proposal,  the  City  may  waive  minor 
informalities  or  allow  the  proposer  to  correct  them.  According  to  Chapter  30B,  minor 
informalities  are  minor  deviations,  insignificant  mistakes,  and  matters  of  form  rather 
than  substance  of  the  proposal  which  can  be  waived  or  corrected  without  prejudice  to 
other  offerors,  potential  offerors,  or  the  governmental  body. 

The  City  will  correct  a  proposal  if  a  mistake  and  the  intended  offer  are  clearly  evident 
on  the  face  of  the  proposal  document.  In  such  a  case,  the  City  will  make  the  correction, 
and  notify  the  proposer  in  writing;  the  proposer  will  not  be  permitted  to  withdraw  its 
proposal.  Other  than  to  make  such  a  correction,  the  City  will  not  correct  or  change  a 
proposal. 


(5.3)  Minimum  Evaluation  Criteria 

Minimum  Evaluation  Criteria  reflect  those  standards  or  attributes  which  are  essential  to 
satisfactory  performance  of  the  contract  to  be  entered  into  pursuant  to  this  RFP.  The 
minimum  criteria  will  be  used  to  identify  responsive  and  responsible  proposals.  A 
responsive  proposal  is  one  that  contains  all  of  the  forms  and  information,  and  offers  all 
of  the  equipment,  supplies  or  services  requested  in  the  RFP.  A  responsible  proposal  is 
one  that  demonstrates  the  capability,  integrity,  and  reliability  of  the  proposer  to  perform 
under  the  contract  to  be  awarded. 

If  a  proposal  fails  to  satisfy  any  of  the  standards  set  forth  as  minimum  criteria,  it 
automatically  will  be  eliminated  from  further  consideration. 
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(5.4)  Evaluation  of  Responsive  and  Responsible  Proposals  Using  the  Comparative 
Evaluation  Criteria  Contained  in  the  RFP 

All  responsive  proposals  from  responsible  proposers  (i.e.,  those  that  meet  the  minimum 
criteria)  will  be  evaluated  further.  The  evaluators  will  prepare  written  evaluations  for 
each  responsive  proposal.  Those  proposals  that  are  both  responsive  and  responsible 
will  be  evaluated  under  the  comparative  evaluation  criteria  set  forth  in  Section  7.0  of 
the  RFP. 

The  four  rating  categories  set  forth  in  Chapter  30B  will  be  used  to  evaluate  each 
proposal  that  meets  the  minimum  criteria.  The  rating  categories  are  —  "Highly 
Advantageous,"  "Advantageous,"  "Not  Advantageous,"  and  "Unacceptable".  For  each 
comparative  evaluation  criterion,  the  City  will  assign  a  rating  of  "Highly 
Advantageous,"  "Advantageous,"  "Not  Advantageous,"  or  "Unacceptable".  The  City 
will  also  assign  a  composite  rating  of  "Highly  Advantageous,"  "Advantageous,"  "Not 
Advantageous,"  or  "Unacceptable"  to  each  proposal.  The  record  of  the  proposal 
evaluations  will  show  the  rating  assigned  for  each  evaluation  criterion,  the  reasons  for 
each  rating,  the  composite  rating  assigned  to  the  proposal,  and  the  reasons  for  the 
composite  rating. 


(5.5)  Assigning  Composite  Ratings 

After  proposals  have  been  assigned  ratings  on  the  basis  of  each  evaluation  criterion, 
evaluators  will  assign  composite  ratings  to  the  proposals.  The  written  explanation 
accompanying  each  composite  rating  will  state  the  reasons  for  each  composite  rating. 


(5.6)  Determining  the  Most  Advantageous  Proposal 

The  most  advantageous  proposal  shall  be  determined  from  responsible  and  responsive 
proposals  by  taking  into  consideration  the  price  and  the  evaluation  criteria  contained 
herein.  Evaluating  the  proposals  and  determining  the  most  advantageous  proposal  is  a 
four  step  process  that  includes  the  following: 

1)  Application  of  minimum  criteria 

2)  Application  of  comparative  criteria 

3)  Assigning  a  composite  rating 

4)  Selecting  the  most  advantageous  proposal 


Important  Note:  QUALITY  and  SPECIFICITY  OF  PROPOSALS 

The  proposal  submitted  by  a  Vendor  is  intended  to  be  viewed  by  the  City  as  the  most 
significant  and  the  primary  source  of  information  and  materials  relied  upon  for  the 
evaluation.  The  City  will  assess  the  proposal  on  the  basis  of  the  degree  to  which  it 
addresses  the  RFP's  requirements  in  regard  to  its  quality  and  specificity  of  the  required 
responses  and  submissions  including,  but  not  limited  to,  forms,  questionnaires,  resumes, 
and  documentation.  The  proposal  will  also  be  utilized  as  a  gage  of  a  Vendor's 
capabilities  of  providing  the  required  systems  and  services 
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The  Vendor  should  provide  all  the  responses  particularly  with  the  content  and  in  a 
manner  as  explained  and  described  in  Section  8.0  of  this  RFP,  Sources  of  Information 
for  Evaluating  Proposals  In  Accordance  with  the  Comparative  Criteria.  The  Vendor 
should  address  all  aspects  of  the  proposal  in  a  concise  and  meaningful  fashion  and  avoid 
inclusion  of  irrelevant  material  and/or  merely  repeating  RFP  wording.  Vendors  should 
clearly  understand  the  critical  value  of  submitting  proposals  characterized  by  their 
quality  and  specificity. 
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SECTION  6.0 
MINIMUM  EVALUATION  CRITERIA 
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SECTION  6.0 
MINIMUM  EVALUATION  CRITERIA 


(6.1)  Overview 

Each  proposal  shall  be  evaluated  to  determine  whether  it  meets  the  submission 
requirements  and  minimum  criteria  specified  herein.  Responsive  and  responsible 
proposals  which  meet  the  minimum  criteria  outlined  in  this  section  of  the  RFP  will  be 
evaluated  for  the  Comparative  Evaluation  Criteria  set  forth  in  section  7.0,  'Comparative 
Evaluation  Criteria',  of  this  RFP. 


(6.2)  Listing  of  Minimum  Criteria  and  the  use  of  Response  Form 

The  minimum  evaluation  criteria  for  this  RFP  are  set  forth  in  the  following  paragraph, 
'6.3,  Minimum  Evaluation  Criteria'. 

To  respond  to  the  minimum  evaluation  criteria,  Proposers  must  use  the  Minimum 
Evaluation  Criteria  Response  Form  ("FORM  A")  which  is  included  in  the  'Forms' 
section  of  this  RFP.  The  Proposer  may  attach  additional  pages  to  this  form. 


(6.3)  MINIMUM  EVALUATION  CRITERIA 


1.        Company  Experience  -  The  proposer  must  possess  at  least  two  (2)  years  direct 
experience  within  the  past  five  (5)  years  in  providing  large-scale  and  full  service 
PVPMISS  technical  and  operational  requirements  and  have  processed  at  least 
500,000  parking  tickets  each  year;  each  one  of  the  required  two  years  processing 
experience  must  be  for  a  single  client  which  issued  at  least  200,000  parking 
tickets.  The  proposer  must  indicate  which  of  the  RFP  systems,  subsystems  and 
services,  as  defined  in  the  section  of  this  RFP  entitled  "Scope  of  Services",  were 
utilized  throughout  each  of  the  required  years  of  experience.  The  proposer  must 
clearly  specify  any  RFP-required  system  elements  which  were  NOT  operational 
throughout  the  indicated  years  of  experience. 


2.        Required  Systems  /  Subsystems  /  Services  -  The  proposer  must  include  all 

systems,  subsystems  and  services,  as  defined  in  the  section  of  this  RFP  entitled 
"Scope  of  Services",  as  part  of  the  proposal. 


3.        Proposal  Deposit  -  The  proposer  must  submit  a  proposal  deposit  in  the  form  of  a 
certified  check  drawn  on,  or  a  treasurer's  or  cashier's  check  issued  by,  a 
responsible  bank  or  trust  company  and  made  payable  to  the  City  of  Boston,  or  a 
proposal  bond  issued  by  a  surety  company  qualified  to  do  business  in  the 
Commonwealth  and  satisfactory  in  form  to  the  City.  The  amount  of  such  check 
or  the  penal  sum  of  such  bond  shall  be  $25,000  (twenty-five  thousand  dollars). 
Such  proposal  deposit  shall  accompany  the  original  signed  Technical  Proposal 
received  at  the  Transportation  Department/Office  of  the  Parking  Clerk. 
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4.  Performance  Bond  -  The  proposer  must  agree  to  provide,  at  the  City's  discretion 
as  security  to  guarantee  the  faithful  performance  of  any  contract  awarded 
pursuant  to  this  RFP  a  performance  bond  of  a  surety  company  authorized  to  do 
business  in  the  Commonwealth  of  Massachusetts  and  satisfactory  in  form  to  the 
Awarding  Authority  in  the  amount  of  one  million  dollars  ($1,000,000). 

5.  Proposal  Format  -  Each  proposer  must  submit  its  proposal  in  conformance  with 
the  requirements  set  forth  in  the  section  of  this  RFP  entitled  "Information  and 
Instructions  to  Proposers  Regarding  Submittal  of  the  Non-Cost  (Technical)  and 
Cost  Proposals  and  the  Evaluation  Thereof"  and  the  section  of  this  RFP  entitled 
"Submission  of  the  Complete  Proposal".  The  proposer  must  include  all  required 
forms,  responses  and  references.  NOTE:  The  proposer  MUST  submit  separate, 
clearly  labeled  and  sealed  technical  and  cost  proposals. 


5. A.     Cost  Submittal  -  The  proposer  must  submit  its  cost  /  price  proposal  (one  original 
and  one  copy)  separate  from  its  technical  proposal  in  a  sealed  package  clearly 
labeled  in  conformance  with  the  requirements  set  forth  in  the  section  of  this  RFP 
entitled  "Information  and  Instructions  to  Proposers  Regarding  Submittal  of  the 
Non-Cost  (Technical)  and  Cost  Proposals  and  the  Evaluation  Thereof". 


6.       Turnkey  -  The  proposer  must  agree  to  provide  all  systems,  subsystems  and 

services  as  defined  in  the  section  of  this  RFP  entitled  "Scope  of  Services",  ready 
to  operate  in  a  production  environment  on  July  1,  2010. 


7.        Personnel  -  The  proposer  must  include  all  of  the  required  RFP  forms  and 

detailed  current  resumes  for  all  of  the  key  personnel  and  as  requested  in  this 
RFP. 


7.A     Project  Team  -  The  proposer  must  agree  that  the  City  shall  retain  the  right  to 

interview  and  approve/disapprove  of  any  potential  Boston  project  team  member 
or  key  personnel.  Additionally,  if  a  key  individual's  or  team  member's 
performance  proves  unsatisfactory  to  the  City  or  if  personality  conflicts  impair 
performance,  the  proposer  must  agree  that  the  City  reserves  the  right  to  require 
that  person's  removal  from  the  Boston  team. 


8.        Adaptability  -  The  proposer  must  agree  to  adapt  and  upgrade  its  staffing, 

equipment,  software  and  other  resources  to  respond  to  and  fulfill  the  variable 
needs  of  the  City  throughout  the  course  of  any  contract  awarded  pursuant  to  this 
RFP  without  additional  cost  to  the  City. 


9.        Financial  Strength  -  The  proposer  must  be  financially  solvent  (i.e.  currently  not 
bankrupt  and  currently  not  considering  filing  for  bankruptcy  or  bankruptcy 
protection)  and  must  provide  documentation  to  support  that  fact.  At  a  minimum, 
the  proposer  must  provide  audited  financial  statements  for  each  of  the  three  (3) 
most  recent  fiscal  years.  If  the  proposer's  firm  is  a  subsidiary  of  a  larger 
organization,  this  information,  if  available,  should  be  provided  for  both  the 
parent  and  the  proposing  entity. 
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User  Guides  and  Specifications  for  Program/System  Areas  and  Service  Areas 
(with  the  emphasis  on  system  areas)  -  The  proposer  must  agree  to  provide  the 
actual  documentation  for  system,  subsystem  and  service  areas  (with  the 
emphasis  on  systems  and  subsystems).  This  constitutes  the  proposer's 
description  and  provision  of  actual  documentation  relative  to  each  RFP  system 
or  service  function  such  as:  user  guides/manuals  for  on-line  systems  viewing; 
on-line  systems  processing,  MIS  and  other  reports,  etc.;  user-oriented  system 
processing  explanations;  user-oriented  criteria  and  condition  statements  for 
system  activities,  events  and  functions;  user-oriented  functional  specifications 
and  descriptions  of  software  programs  and  relationships  between  different 
programs;  user-oriented  descriptions  of  operational  service  functions;  etc.  In  the 
event  that  certain  of  this  information  represents  trade  secrets  or  proprietary 
information,  the  proposer  must  agree  to  make  said  material  available  to  the  City 
at  a  location  to  be  determined  by  the  proposer,  so  long  as  said  location  is 
situated  within  approximately  a  one  (1)  mile  radius  of  Boston  City  Hall.  The 
proposer  must  agree  to  allow  evaluators  unrestricted  access,  for  the  purpose  or 
review  and  'note  taking',  to  said  documentation  during  the  hours  of  9:00  a.m. 
and  5:00  p.m.,  from  Monday  through  Friday  (excluding  holidays),  during  the 
evaluation  phase  of  this  RFP.  The  before  mentioned  access  for  any  single 
review  visit  shall  be  arranged  a  minimum  of  twenty-four  (24)  hours  prior  to  said 
visit. 
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SECTION  7.0 
COMPARATIVE  EVALUATION  CRITERIA 
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SECTION  7.0 

(7.0.1)  LISTING  OF  COMPARATIVE  EVALUATION  CRITERIA 


The  Comparative  Evaluation  Criteria  set  forth  in  this  section  of  the  RFP  shall  be  used  to 
evaluate  responsible  and  responsive  proposals.  The  Comparative  Evaluation  Criteria 
are: 


1)  Company  PVPMISS  Experience,  Capability,  Qualifications  and  Demonstrated 
Efficient  and  Effective  Performance 


2)  Compliance  with  Scope  of  Services 


3)  Operations/Management  Plan  and  Plan  of  Services  and  Personnel  Depth, 
Qualifications,  Experience  and  Performance 


4)  RMV  Interface  Experience,  Knowledge,  Capability  and  Demonstrated  Efficient  and 
Effective  Performance 
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(7.1)  COMPARATIVE  CRITERION  #  1: 


COMPANY  PVPMISS  EXPERIENCE,  CAPABILITY,  QUALIFICATIONS 
AND  DEMONSTRATED  EFFICIENT  AND  EFFECTIVE  PERFORMANCE 
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CRITERION  #  1: 

COMPANY  PVPMISS  EXPERIENCE,  CAPABILITY,  QUALIFICATIONS 
AND  DEMONSTRATED  EFFICIENT  AND  EFFECTIVE  PERFORMANCE 

HIGHLY  ADVANTAGEOUS: 


1  The  Proposer  has  a  minimum  of  five  (5)  years  direct  experience  in  providing  large- 
scale  and  full-service  PVPMISS  technical  and  operational  requirements  similar  to 
Boston's  (in  terms  such  as  size,  scope/range  of  systems  and  operations,  level  of 
integration,  complexity,  number  and  types  of  transactions,  edits  and  quality  controls, 
customer  service  capabilities),  of  which  a  minimum  of  five  (5)  years  experience  is 
within  the  time  period  July  1,  2003  through  December  14,  2009. 


2  It  is  determined  that  the  proposal  thoroughly,  comprehensively  and  clearly  details, 
documents,  substantiates  and  demonstrates  extensive  previous  and  current  direct 
PVPMISS  experience,  capability,  qualifications  and  performance  with  all  or  virtually 
all  of  the  required  systems  and  subsystems  and  this  assessment  is  supported  by  the 
efficient  and  effective  provision  of  systems  and  subsystems  in  PVPMISS 
installations  similar  and  comparable  to  Boston  (in  terms  such  as  size,  scope/range  of 
systems  and  operations,  level  of  integration,  complexity,  number  and  types  of 
transactions,  edits  and  quality  controls,  customer  service  capabilities,  value  and 
benefits)  and  provides  the  highest  level  of  assurance  that  disruption  or  risk  to  the 
City's  current  level  and  quality  of  enforcement,  customer  service/public 
responsiveness,  processing  components  and  efforts,  and  collection  rates  can  be 
prevented  or  extremely  minimized. 


3  It  is  determined  that  the  proposal  thoroughly,  comprehensively  and  clearly  details, 
documents,  substantiates  and  demonstrates  extensive  previous  and  current  direct 
PVPMISS  experience,  capability,  qualifications  and  performance  with  an  extensive 
number  of  the  required  RFP  SERVICE  FUNCTIONS  (i.e.,  lockbox  operations, 
payment  processing,  system  updates,  receipt  of  tickets,  ticket  data  input,  notice 
generation  and  mailing,  etc.),  and  this  assessment  is  supported  by  the  efficient  and 
effective  provision  of  these  service  functions  in  PVPMISS  installations  similar  and 
comparable  to  Boston  (in  terms  such  as  size,  scope/range  of  internal  operations,  level 
of  integration,  complexity,  number  and  types  of  transactions,  edits  and  quality 
controls,  customer  service  capabilities,  value  and  benefits)  and  provides  the  highest 
level  of  assurance  that  disruption  or  risk  to  the  City's  current  level  and  quality  of 
enforcement,  customer  service/public  responsiveness,  processing  components  and 
efforts,  and  collection  rates  can  be  prevented  or  extremely  minimized. 
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CRITERION  #  1: 

COMPANY  PVPMISS  EXPERIENCE,  CAPABILITY,  QUALIFICATIONS 
AND  DEMONSTRATED  EFFICIENT  AND  EFFECTIVE  PERFORMANCE 
HIGHLY  ADVANTAGEOUS:  (continued) 


4  The  proposer  thoroughly,  comprehensively  and  clearly  documents,  details, 
substantiates  and  demonstrates  the  PVPMISS  evolution  (in  terms  such  as 
background,  growth,  direct  and  indirect  customer  demands,  ongoing  and  incremental 
improvements,  major  design  or  technological  advances,  testing,  debugging,  and 
implementation)  and  provides  the  highest  level  of  assurance  that  the  PVPMISS  being 
proposed  is  thoroughly  debugged,  proven  and  successful  in  operating/production 
environment(s)  similar  and  comparable  to  Boston  and  will  be  highly  efficient  and 
effective  in  terms  of  the  RFP  requirements. 


5     The  structural  and  data  management  design  and  approach  and  software  (including 
Data  Base  Management  System  [DBMS],  if  applicable,)  of  the  proposer's 
PVPMISS  has  been  extensively  and  successfully  utilized  in  PVPMISS  installations 
similar  and  analogous  to  Boston  (in  terms  such  as  size,  volumes,  scope/range  of 
systems  and  operations,  level  of  integration,  sophistication,  complexity,  efficiency 
and  effectiveness),  in  regards  to: 

a)  data  management 

b)  how  data  items  are  related  to  each  other 

c)  the  file  structure/data  structure  utilized  by  the  software  system 

d)  the  organization,  coherence,  linkage  and  unity  of  the  various  constituent 
system  elements 

e)  handling  the  large  number  and  numerous  types  of  transactions 

f)  the  capabilities  and  means  of  identifying,  scheduling  and  producing 
transactions,  events  and  activities  on  very  flexible  schedules,  e.g.,  the 
production  of  the  same  notice  type  on  a  daily  basis  at  various  quantity  levels 
specified  by  the  City 

g)  those  elements  of  a  proposer's  PVPMISS  that  actually  execute  actions  and 
events,  and 

h)  ease  of  modification  and  enhancement; 


are  clearly  and  comprehensively  detailed,  explained  and  documented  and  are 
determined  to  provide  a  unified,  extremely  efficient  and  effective  multi-application, 
INTEGRATED  set  of  systems,  subsystems,  system  elements  and  collection  of  data 
—  and  to  accommodate  the  extremely  efficient  and  effective  development  and 
implementation  of  new  applications,  and  modification  or  expansion  of  existing 
applications,  in  such  a  manner  as  would  eliminate  or  extremely  minimize  any  risk 
to  the  quality  of  performance  or  operation  of  existing  applications  and  functions. 
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CRITERION  #  1: 

COMPANY  PVPMISS  EXPERIENCE,  CAPABILITY,  QUALIFICATIONS 
AND  DEMONSTRATED  EFFICIENT  AND  EFFECTIVE  PERFORMANCE 


HIGHLY  ADVANTAGEOUS:  (continued) 


6  The  proposer  clearly  documents  extensive  current  or  pending  contractual 

commitments  (in  PVPMISS  installations  similar  and  comparable  to  Boston)  which 
would  significantly  overlap  the  time  frame  of  the  proposed  Boston  contract  and 
which  would  potentially  benefit  the  operations  of  the  City  vis-a-vis  access  to  and 
sharing  of  ideas,  new  system  developments,  improvements  or  expansions  to  existing 
systems  and  services,  customer  service/public  responsiveness  innovations, 
transportation  management  solutions/approaches,  etc.,  that  would  be  initiated,  tested 
and  debugged  by  non-Boston  proposer  clients. 
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CRITERION  #  1: 

COMPANY  PVPMISS  EXPERIENCE,  CAPABILITY,  QUALIFICATIONS 
AND  DEMONSTRATED  EFFICIENT  AND  EFFECTIVE  PERFORMANCE 

ADVANTAGEOUS: 


1  The  proposer  has  a  minimum  of  three  (3)  years  direct  experience  in  providing  large- 
scale  and  full-service  PVPMISS  technical  and  operational  requirements  similar  to 
Boston's  (in  terms  such  as  size,  scope/range  of  systems  and  operations,  level  of 
integration,  complexity,  number  and  types  of  transactions,  edits  and  quality  controls, 
customer  service  capabilities),  of  which  a  minimum  of  two  (2)  years  experience  is 
within  the  time  period  July  1,  2004  through  December  14,  2009. 


2  It  is  determined  that  the  proposal  thoroughly,  comprehensively  and  clearly  details, 
documents,  substantiates  and  demonstrates  extensive  previous  and  current  direct 
PVPMISS  experience,  capability,  qualifications  and  performance  with  all  or  virtually 
all  of  the  required  systems  and  subsystems  and  this  assessment  is  supported  by  the 
efficient  and  effective  provision  of  systems  and  subsystems  in  PVPMISS 
installations  similar  and  comparable  to  Boston  (in  terms  such  as  size,  scope/range  of 
systems  and  operations,  level  of  integration,  complexity,  number  and  types  of 
transactions,  edits  and  quality  controls,  customer  service  capabilities,  value  and 
benefits)  and  the  proposal  provides  a  high  level  of  assurance  that  disruption  or  risk  to 
the  City's  current  level  and  quality  of  enforcement,  customer  service/public 
responsiveness,  processing  components  and  efforts,  and  collection  rates  can  be 
prevented  or  extremely  minimized. 


3  It  is  determined  that  the  proposal  thoroughly,  comprehensively  and  clearly  details, 
documents,  substantiates  and  demonstrates  extensive  previous  and  current  direct 
PVPMISS  experience,  capability,  qualifications  and  performance  with  an  extensive 
number  of  the  required  RFP  SERVICE  FUNCTIONS  (i.e.,  lockbox  operations, 
payment  processing,  system  updates,  receipt  of  tickets,  ticket  data  input,  notice 
generation  and  mailing,  etc.),  and  this  assessment  is  supported  by  the  efficient  and 
effective  provision  of  service  functions  in  PVPMISS  installations  similar  and 
comparable  to  Boston  (in  terms  such  as  size,  scope/range  of  internal  operations,  level 
of  integration,  complexity,  number  and  types  of  transactions,  edits  and  quality 
controls,  customer  service  capabilities,  value  and  benefits)  and  provides  a  high  level 
of  assurance  that  disruption  or  risk  to  the  City's  current  level  and  quality  of 
enforcement,  customer  service/  public  responsiveness,  processing  components  and 
efforts,  and  collection  rates  can  be  prevented  or  extremely  minimized. 


132 


CRITERION  #  1: 

COMPANY  PVPMISS  EXPERIENCE,  CAPABILITY,  QUALIFICATIONS 
AND  DEMONSTRATED  EFFICIENT  AND  EFFECTIVE  PERFORMANCE 

ADVANTAGEOUS:  (continued) 


4  The  proposer  thoroughly,  comprehensively  and  clearly  documents,  details, 
substantiates  and  demonstrates  the  PVPMISS  evolution  (in  terms  such  as 
background,  growth,  direct  and  indirect  customer  demands,  ongoing  and  incremental 
improvements,  major  design  or  technological  advances,  testing,  debugging,  and 
implementation)  and  provides  a  high  level  of  assurance  that  the  PVPMISS  being 
proposed  is  thoroughly  debugged,  proven  and  successful  in  operating/production 
environment(s)  similar  and  comparable  to  Boston  and  will  be  efficient  and  effective 
in  terms  of  the  RFP  requirements. 


5     The  structural  and  data  management  design  and  approach  and  software  (including 
Data  Base  Management  System  [DBMS],  if  applicable)  of  the  proposer's 
PVPMISS,  has  been  extensively  and  successfully  utilized  in  PVPMISS  installations 
similar  and  analogous  to  Boston  (in  terms  such  as  size,  volumes,  scope/range  of 
systems  and  operations,  etc.),  in  regards  to: 

a)  data  management 

b)  how  data  items  are  related  to  each  other 

c)  the  file  structure/data  structure  utilized  by  the  software  system 

d)  the  organization,  coherence,  linkage  and  unity  of  the  various  constituent 
system  elements 

e)  handling  the  large  number  and  numerous  types  of  transactions 

f)  the  capabilities  and  means  of  identifying,  scheduling  and  producing 
transactions,  events  and  activities  on  very  flexible  schedules,  e.g.,  the 
production  of  the  same  notice  type  on  a  daily  basis  at  various  quantity  levels 
specified  by  the  City 

g)  those  elements  of  a  proposer's  PVPMISS  that  actually  execute  actions  and 
events,  and 

h)  ease  of  modification  and  enhancement; 


are  clearly  and  comprehensively  detailed,  explained  and  documented  and  are 
determined  to  provide  an  efficient  and  effective  multi-application,  INTEGRATED 
set  of  systems,  subsystems,  system  elements  and  collection  of  data  -  and  to 
accommodate  the  efficient  and  effective  development  and  implementation  of  new 
applications,  and  modification  or  expansion  of  existing  applications,  in  such  a 
manner  as  would  minimize  or  eliminate  any  risk  to  the  quality  of  performance  or 
operation  of  existing  applications  and  functions. 
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CRITERION  #  1: 

COMPANY  PVPMISS  EXPERIENCE,  CAPABILITY,  QUALIFICATIONS 
AND  DEMONSTRATED  EFFICIENT  AND  EFFECTIVE  PERFORMANCE 

NOT  ADVANTAGEOUS: 


1  The  proposer  has  less  than  three  (3)  years  direct  experience  in  providing  large-scale 
and  full-service  PVPMISS  technical  and  operational  requirements  similar  to  Boston's 
(in  terms  such  as  size,  scope/range  of  systems  and  operations,  level  of  integration, 
complexity,  number  and  types  of  transactions,  edits  and  quality  controls,  customer 
service  capabilities),  and/or  less  than  two  (2)  years  of  that  experience  is  within  the 
time  period  July  1,  2004  through  December  14,  2009. 


2  It  is  determined  that  the  proposal  details,  documents,  substantiates  and  demonstrates 
only  marginal  previous  or  current  direct  PVPMISS  experience,  capability, 
qualifications  and  performance  —  in  general  in  regards  to,  or  with  an  unacceptable 
number  of,  or  with  certain  major  systems  and  subsystems  and  the  assessment  is 
supported  by  the  provision  of  these  systems  and  subsystems  in  at  least  one  PVPMISS 
installation  similar  and  comparable  to  Boston  (in  terms  such  as  size,  scope/range  of 
systems  and  operations,  etc.)  and  the  proposal  provided  only  a  marginal  level  of 
assurance  that  disruption  or  risk  to  the  City's  current  level  and  quality  of 
enforcement,  public  responsiveness,  processing  components  and  efforts,  and 
collection  rates  would  be  prevented  or  extremely  minimized,  or  the  proposal  was 
sufficiently  unclear  or  lacked  significant  details,  etc.  required  to  adequately  assess 
the  relative  value  of  proposer  experience,  capability,  qualifications  and  performance 
above  marginal. 


3  It  is  determined  that  the  proposal  details,  documents,  substantiates  and  demonstrates 
only  marginal  previous  or  current  direct  PVPMISS  experience,  capability, 
qualifications  and  performance  —  in  general  in  regards  to,  or  with  an  unacceptable 
number  of,  or  with  certain  major  RFP  SERVICE  FUNCTIONS  (i.e.,  lockbox 
operations,  payment  processing,  system  updates,  receipt  of  tickets,  ticket  data  input, 
notice  generation  and  mailing,  etc.)  and  the  assessment  is  supported  by  the  provision 
of  these  service  functions  in  at  least  one  PVPMISS  installation  similar  and 
comparable  to  Boston  (in  terms  such  as  size,  scope/range  of  systems  and  operations, 
etc.)  and  the  proposal  provides  only  a  marginal  level  of  assurance  that  disruption  or 
risk  to  the  City's  current  level  and  quality  of  enforcement,  public  responsiveness, 
processing  components  and  efforts,  and  collection  rates  would  be  prevented  or 
extremely  minimized,  or  the  proposal  is  sufficiently  unclear  or  lacks  significant 
details,  etc.  required  to  adequately  assess  the  relative  value  of  proposer  experience, 
capability,  qualifications  and  performance  above  a  marginal  rating. 
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CRITERION  #  1: 

COMPANY  PVPMISS  EXPERIENCE,  CAPABILITY,  QUALIFICATIONS 
AND  DEMONSTRATED  EFFICIENT  AND  EFFECTIVE  PERFORMANCE 

NOT  ADVANTAGEOUS:  (continued) 


4  The  proposer  documents,  details,  substantiates  and  demonstrates  its  PVPMISS 
evolution  (in  terms  such  as  background,  growth,  direct  and  indirect  customer 
demands,  ongoing  and  incremental  improvements,  major  design  or  technological 
advances,  testing,  debugging,  and  implementation)  to  an  extent  that  only  provides  a 
marginal  level  of  assurance  that  the  PVPMISS  being  proposed  is  thoroughly 
debugged,  proven  and  successful  in  operating/production  environment(s)  similar  and 
comparable  to  Boston  and  will  be  efficient  and  effective  in  terms  of  the  RFP 
requirements,  or  the  proposal  is  sufficiently  unclear  or  lacks  significant  details,  etc. 
required  to  adequately  assess  the  response  above  a  marginal  rating. 


5  The  structural  and  data  management  design  and  approach  or  software  (including 
Data  Base  Management  System  [DBMS],  if  applicable)  of  the  proposer's  PVPMISS, 
has  been  extensively  and  successfully  utilized  in  at  least  one  PVPMISS  installations 
similar  and  analogous  to  Boston  (in  terms  such  as  size,  volumes,  scope/range  of 
systems  and  operations,  etc.),  in  regards  to: 

a)  data  management 

b)  how  data  items  are  related  to  each  other 

c)  the  file  structure/data  structure  utilized  by  the  software  system 

d)  the  organization,  coherence,  linkage  and  unity  of  the  various  constituent  system 
elements 

e)  handling  the  large  number  and  numerous  types  of  transactions 

f)  the  capabilities  and  means  of  identifying,  scheduling  and  producing  transactions, 
events  and  activities  on  very  flexible  schedules,  e.g.,  the  production  of  the  same 
notice  type  on  a  daily  basis  at  various  quantity  levels  specified  by  the  City 

g)  those  elements  of  a  proposer's  PVPMISS  that  actually  execute  actions  and  events, 
and 

h)  ease  of  modification  and  enhancement; 


is  only  marginally  explained  and  documented  (in  terms  of  level  of  detail,  clarity 
and/or  comprehensiveness)  so  that  the  features  and  benefits  of  the  proposer's  design 
and  approach  could  not  be  adequately  assessed;  and/or,  is  determined  to  provide  only 
a  marginally  efficient  or  effective  multi-application,  INTEGRATED  set  of  systems, 
subsystems,  system  elements  and  collection  of  data  —  or  is  determined  to 
accommodate  only  a  marginally  efficient  or  effective  development  and 
implementation  of  new  applications,  or  modification  or  expansion  of  existing 
applications,  in  such  a  manner  as  would  provide  undue  risk  to  the  quality  of 
performance  or  operation  of  existing  applications  and  functions. 


135 


CRITERION  #  1: 

COMPANY  PVPMISS  EXPERIENCE,  CAPABILITY,  QUALIFICATIONS 
AND  DEMONSTRATED  EFFICIENT  AND  EFFECTIVE  PERFORMANCE 


UNACCEPTABLE: 


1  The  proposer  has  less  than  three  (3)  years  direct  experience  in  providing  large-scale 
and  full-service  PVPMISS  technical  and  operational  requirements  similar  to  Boston's 
(in  terms  such  as  size,  scope/range  of  systems  and  operations,  level  of  integration, 
complexity,  number  and  types  of  transactions,  edits  and  quality  controls,  customer 
service  capabilities),  and  less  than  two  (2)  years  experience  within  the  time  period 
July  1,  2004  through  December  14,  2009. 


2  It  is  determined  that  the  proposer  details,  documents,  substantiates  and  demonstrates 
generally  deficient  previous  or  current  direct  PVPMISS  experience,  capability, 
qualifications  and  performance  in  general  in  regards  to,  or  with  an  unacceptable 
number  or  with  certain  major  systems  and  subsystems  and  this  assessment  is 
supported  by  the  provision  of  these  systems  and  subsystems  in  at  least  one  PVPMISS 
installation  similar  and  comparable  to  Boston  (in  terms  such  as  size,  scope/range  of 
systems  and  operations,  etc.)  or  the  proposal  is  sufficiently  unclear  or  lacks 
significant  details,  etc.  required  to  adequately  assess  the  relative  value  of  proposer 
experience,  capability,  qualifications  and  performance  above  deficient  or  the 
proposal  provides  a  generally  deficient  level  of  assurance  that  disruption  or  risk  to 
the  City's  current  level  and  quality  of  enforcement,  public  responsiveness,  processing 
components  and  efforts,  and  collection  rates  would  be  prevented  or  extremely 
minimized  or  it  is  assessed  as  generally  deficient  as  previous  or  current  direct 
PVPMISS  experience,  capability,  qualifications  and  performance  with  the  required 
RFP  systems  and  subsystems  is  not  based  upon  their  provision  of  systems  and 
subsystems  in  at  least  one  PVPMISS  installation  similar  and  comparable  to  Boston 
(in  terms  such  as  size,  scope/range  of  systems  and  operations,  etc.). 


3  It  is  determined  that  the  proposal  details,  documents,  substantiates  and  demonstrates 
generally  deficient  previous  or  current  direct  PVPMISS  experience,  capability, 
qualifications  and  performance  in  general  in  regards  to,  or  with  an  unacceptable 
number  or  with  certain  major  RFP  SERVICE  FUNCTIONS  (i.e.,  lockbox 
operations,  payment  processing,  etc.)  and  this  assessment  is  supported  by  the 
provision  of  services  in  at  least  one  PVPMISS  installation  similar  and  comparable  to 
Boston  (in  terms  such  as  size,  scope/range  of  systems  and  operations,  etc.)  or  the 
response  is  generally  deficient  in  regards  to  clarity  or  detail,  etc.  required  to 
adequately  assess  the  relative  value  of  proposer  experience,  capability,  qualifications 
and  performance  above  generally  deficient  or  it  provides  only  a  generally  deficient 
level  of  assurance  that  disruption  or  risk  to  the  City's  current  level  and  quality  of 
enforcement,  public  responsiveness,  processing  components  and  efforts,  and 
collection  rates  would  be  prevented  or  extremely  minimized  or  it  is  assessed  as 
generally  deficient  as  previous  and  current  direct  PVPMISS  experience,  capability, 
qualifications  and  performance  with  the  required  RFP  SERVICE  FUNCTIONS  are 
not  based  upon  their  provision  of  systems  and  subsystems  in  at  least  one  PVPMISS 
installation  similar  and  comparable  to  Boston  (in  terms  such  as  size,  scope/range  of 
systems  and  operations,  etc.). 
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CRITERION  #  1: 

COMPANY  PVPMISS  EXPERIENCE,  CAPABILITY,  QUALIFICATIONS 
AND  DEMONSTRATED  EFFICIENT  AND  EFFECTIVE  PERFORMANCE 

UNACCEPTABLE:  (continued) 


4  The  proposer  documents,  details,  substantiates  and  demonstrates  its  PVPMISS 
evolution  (in  terms  such  as  background,  growth,  direct  and  indirect  customer 
demands,  ongoing  and  incremental  improvements,  major  design  or  technological 
advances,  testing,  debugging,  and  implementation)  to  an  extent  that  only  provides  a 
generally  deficient  level  of  assurance  that  the  PVPMISS  being  proposed  is 
thoroughly  debugged,  proven  and  successful  in  operating/production  environment(s) 
similar  and  comparable  to  Boston  and  will  be  efficient  and  effective  in  terms  of  the 
RFP  requirements  or  the  response  is  sufficiently  unclear  or  lacks  significant  details, 
etc.  required  to  adequately  assess  the  response  above  a  deficient  rating. 


5  The  structural  and  data  management  design  and  approach  or  software  (including 
Data  Base  Management  System  [DBMS],  if  applicable,)  of  the  proposer's  PVPMISS, 
has  been  extensively  and  successfully  utilized  in  at  least  one  PVPMISS  installations 
similar  and  analogous  to  Boston  (in  terms  such  as  size,  volumes,  scope/range  of 
systems  and  operations,  etc.),  in  regards  to: 

a)  data  management 

b)  how  data  items  are  related  to  each  other 

c)  the  file  structure/data  structure  utilized  by  the  software  system 

d)  the  organization,  coherence,  linkage  and  unity  of  the  various  constituent  system 
elements 

e)  handling  the  large  number  and  numerous  types  of  transactions 

f)  the  capabilities  and  means  of  identifying,  scheduling  and  producing  transactions, 
events  and  activities  on  very  flexible  schedules,  e.g.,  the  production  of  the  same 
notice  type  on  a  daily  basis  at  various  quantity  levels  specified  by  the  City 

g)  those  elements  of  a  proposer's  PVPMISS  that  actually  execute  actions  and  events, 
and 

h)  ease  of  modification  and  enhancement; 

is  deficiently  explained  and  documented  (in  terms  of  level  of  detail,  clarity  and/or 
comprehensiveness)  so  as  to  provide  a  negative  assessment  of  the  features  and 
benefits  of  the  proposer's  design  and  approach;  AND/OR,  is  determined  to  provide 
an  inefficient  or  ineffective  multi-application,  INTEGRATED  set  of  systems, 
subsystems,  system  elements  and  collection  of  data  -  or  is  determined  to 
accommodate  the  inefficient  or  ineffective  development  and  implementation  of  new 
applications,  or  modification  or  expansion  of  existing  applications,  in  such  a  manner 
as  would  provide  substantial  risk  or  potential  for  disruption  to  the  quality  of 
performance  or  operation  of  existing  applications  and  functions,  or  is  not  extensively 
and  successfully  utilized  in  at  least  one  PVPMISS  installations  similar  and  analogous 
to  Boston  (in  terms  such  as  size,  volumes,  scope/range  of  systems  and  operations, 
etc.). 
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(7.2)  COMPARATIVE  CRITERION  #  2; 
COMPLIANCE  WITH  SCOPE  OF  SERVICES 
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CRITERION  #  2: 
COMPLIANCE  WITH  SCOPE  OF  SERVICES 


HIGHLY  ADVANTAGEOUS: 


1  The  proposer's  response  provides  details,  documentation,  explanations  and 
descriptions  relative  to  the  RFP  requirements  that  are  extremely  and  uniformly 
thorough,  comprehensive,  clear,  detailed  and  specific  —  over  and  beyond  the 
substantial  detail  provided  in  the  RFP  so  that  the  features  and  benefits  of  the 
proposer's  PVPMISS  could  be  ascertained  —  and  the  content  of  said  responses, 
explanations,  descriptions,  etc.  provides  the  highest  degree  of  assurance  that  the 
proposer  possesses  the  proficiency,  knowledge,  skills,  abilities,  expertise  and 
resources  commensurate  with  the  City's  extremely  high  expectations  and  demands 
for  its  PVPMISS. 


2  The  proposer  clearly  and  comprehensively  provides  an  effective-date-specific 
statement  of  explicit  and  direct  compliance  for  RFP  required  systems,  subsystems, 
services,  performance  specifications  and  any  other  RFP  requirement  and,  in  the  event 
that  said  compliance  would  be  contingent  upon  certain  conditions  or  alternatives, 
those  conditions  or  alternatives  were  determined  to  pose  no,  or  an  extremely 
minimal,  risk  or  potential  for  disruption  to  the  City's  current  level  of  PVPMISS 
activities,  services  and  revenue  —  or  to  the  objectives  of  this  RFP,  particularly  in 
terms  of  timetable  or  the  provision  and  operation  of  efficient  and  effective  system 
and  service  features  and  functionality. 


3  It  is  determined  the  proposal  comprehensively  and  clearly  documents,  substantiates 
and  demonstrates  the  ability  to  provide  full  compliance  with  the  City's  requirements 
and  performance  specifications  for  systems,  subsystems  and  services  and  to  deliver, 
provide  and  operate  systems,  subsystems  and  services  that  would  be  extremely 
beneficial  to  the  City  in  terms  such  as  functionality,  utility,  efficiency  and 
effectiveness. 


4  The  proposer  provides  detailed  and  comprehensive  explanations  and  real-life  (hard- 
copy) illustrations  which  substantiate  and  demonstrate  that  the  proposer's  on-line 
information  system  complies  or  can  easily,  efficiently  and  effectively  be  modified  to 
accommodate  and  comply  with  the  City's  data  and  information  requirements  for  all 
or  virtually  all  RFP  required  systems,  subsystems  and  services. 


5  The  proposer  provides  detailed  and  comprehensive  explanations  and  real-life  (hard- 
copy)illustrations  which  substantiate  and  demonstrate  that  the  proposer's  on-line 
information  system  is  highly  efficient  and  effective  for  all  or  virtually  all  RFP 
required  systems,  subsystems  and  services  in  terms  such  as  public 
responsiveness/customer  service,  ease  of  access,  scrolling,  organization  and 
consolidation  of  data,  integration  of  data,  functionality,  format  and  user-friendliness. 
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CRITERION  #  2: 
COMPLIANCE  WITH  SCOPE  OF  SERVICES 


HIGHLY  ADVANTAGEOUS:  (continued) 


6  The  proposer  comprehensively  and  clearly  documents,  substantiates  and 
demonstrates  its  quality  control  of  data  and  the  content  of  the  response  provides  the 
highest  degree  of  assurance  that  data/information  integrity  and  accurate  processing 
would  be  optimized. 

7  The  features  and  functionality  of  the  proposer's  systems,  subsystems  and  services 
appear  to  provide  the  highest  level  of  assurance  that  the  City's  relevant  operational 
costs  (in  terms  such  as  staffing  levels,  operational  efficiencies,  level  of  required 
oversight)  would  not  be  increased  and  would  be  optimally  minimized  or  reduced. 

8  The  credibility  of  the  proposer's  RFP  responses  in  terms  of  demonstrated  capability 
to  comply  with  specified  requirements  throughout  the  full  term  of  the  proposed 
contract  is  determined  to  be  optimal. 

9  The  proposer  provides  the  highest  level  of  assurance  that  the  City  would  have  the 
ability  to  move  forward  on  July  1,  2010,  (and  throughout  the  full  term  of  the 
proposed  contract)  with  the  continued  generation,  development  and  implementation 
of  on-going  enhancements  and  improvements  to  systems,  system  elements  and 
services. 

10  The  structural  and  data  management  design  and  approach  and  software(including 
Data  Base  Management  System  [DBMS],  if  applicable)  of  the  proposer's  PVPMISS 
(in  terms  such  as  size,  volumes,  scope/range  of  systems  and  operations,  level  of 
integration,  sophistication,  complexity,  efficiency  and  effectiveness),  in  regards  to: 

a)  data  management 

b)  how  data  items  are  related  to  each  other 

c)  the  file  structure/data  structure  utilized  by  the  software  system 

d)  the  organization,  coherence,  linkage  and  unity  of  the  various  constituent 
system  elements 

e)  handling  the  large  number  and  numerous  types  of  transactions 

f)  the  capabilities  and  means  of  identifying,  scheduling  and  producing 
transactions,  events  and  activities  on  very  flexible  schedules,  e.g.,  the 
production  of  the  same  notice  type  on  a  daily  basis  at  various  quantity  levels 
specified  by  the  City 

g)  those  elements  of  a  proposer's  PVPMISS  that  actually  execute  actions  and 
events,  and 

h)  ease  of  modification  and  enhancement; 

are  clearly  and  comprehensively  detailed,  explained  and  documented  and  are 
determined  to  provide  an  extremely  efficient  and  effective  multi-application, 
INTEGRATED  set  of  systems,  subsystems,  system  elements  and  collection  of  data 
—  and  are  determined  to  accommodate  the  extremely  efficient  and  effective 
development  and  implementation  of  new  applications,  and  modification  or 
expansion  of  existing  applications,  in  such  a  manner  as  would  eliminate  or 
extremely  minimize  any  risk  to  the  quality  of  performance  or  operation  of  existing 
applications  and  functions. 
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CRITERION  #  2: 
COMPLIANCE  WITH  SCOPE  OF  SERVICES 


ADVANTAGEOUS: 


1  The  proposer's  response  provides  details,  documentation,  explanations  and 

descriptions,  etc.  relative  to  the  RFP  requirements  that  are  extremely  and  uniformly 
thorough,  comprehensive,  clear,  detailed  and  specific  —  over  and  beyond  the 
substantial  detail  provided  in  the  RFP  so  that  the  features  and  benefits  of  the 
proposer's  PVPMISS  could  be  ascertained  —  and  the  content  of  said  responses, 
explanations,  descriptions,  etc.  provides  a  high  degree  of  assurance  that  the  proposer 
possesses  the  proficiency,  knowledge,  skills,  abilities,  expertise  and  resources 
commensurate  with  the  City's  extremely  high  expectations  and  demands  for  its 
PVPMISS. 


2  The  proposer  clearly  and  comprehensively  provides  an  effective-date-specific 
statement  of  explicit  and  direct  compliance  for  RFP  required  systems,  subsystems, 
services,  performance  specifications  and  any  other  RFP  requirement  and,  in  the  event 
that  said  compliance  would  be  contingent  upon  certain  conditions  or  alternatives, 
those  conditions  or  alternatives  were  determined  to  pose  no,  or  an  extremely 
minimal,  risk  or  potential  for  disruption  to  the  City's  current  level  of  PVPMISS 
activities,  services  and  revenue  —  or  to  the  objectives  of  this  RFP,  particularly  in 
terms  of  timetable  or  the  provision  and  operation  of  efficient  and  effective  system 
and  service  features  and  functionality. 


3  It  is  determined  the  proposal  comprehensively  and  clearly  documents,  substantiates 
and  demonstrates  the  ability  to  provide  full  compliance  with  the  City's  requirements 
and  performance  specifications  for  systems,  subsystems  and  services  and  to  deliver, 
provide  and  operate  systems,  subsystems  and  services  that  would  be  beneficial  to  the 
City  in  terms  such  as  functionality,  utility,  efficiency  and  effectiveness. 


4  The  proposer  provides  detailed  and  comprehensive  explanations  and  real-life  (hard- 
copy) illustrations  which  substantiate  and  demonstrate  that  the  proposer's  on-line 
information  system  complies  or  can  efficiently  and  effectively  be  modified  to 
accommodate  and  comply  with  the  City's  data  and  information  requirements  for  all 
or  virtually  all  RFP  required  systems,  subsystems  and  services. 


5  The  proposer  provides  detailed  and  comprehensive  explanations  and  real-life  (hard- 
copy) illustrations  which  substantiate  and  demonstrate  that  the  proposer's  on-line 
information  system  is  efficient  and  effective  for  all  or  virtually  all  RFP  required 
systems,  subsystems  and  services  in  terms  such  as  public  responsiveness/customer 
service,  ease  of  access,  scrolling,  organization  and  consolidation  of  data,  integration 
of  data,  functionality,  format  and  user-friendliness. 
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CRITERION  #  2: 
COMPLIANCE  WITH  SCOPE  OF  SERVICES 

ADVANTAGEOUS:  (continued) 

6  The  proposer  comprehensively  and  clearly  documents,  substantiates  and 
demonstrates  its  quality  control  of  data  and  the  content  of  the  response  provides  a 
high  degree  of  assurance  that  data/information  integrity  and  accurate  processing 
would  be  optimized. 

7  The  features  and  functionality  of  the  proposer's  systems,  subsystems  and  services 
appear  to  provide  a  high  level  of  assurance  that  the  City's  relevant  operational  costs 
(in  terms  such  as  staffing  levels,  operational  efficiencies,  level  of  required  oversight) 
would  not  be  increased  and  would  be  optimally  minimized  or  reduced. 

8  The  credibility  of  the  proposer's  RFP  responses  in  terms  of  demonstrated  capability 
to  comply  with  specified  requirements  throughout  the  full  term  of  the  proposed 
contract  is  determined  to  be  good. 

9  The  proposer  provides  a  high  level  of  assurance  that  the  City  would  have  the  ability 
to  move  forward  on  July  1,  2010,  (and  throughout  the  full  term  of  the  proposed 
contract)  with  the  continued  generation,  development  and  implementation  of  on- 
going enhancements  and  improvements  to  systems,  system  elements  and  services. 

10  The  structural  and  data  management  design  and  approach  and  software(including 
Data  Base  Management  System  [DBMS],  if  applicable)  of  the  proposer's  PVPMISS 
(in  terms  such  as  size,  volumes,  scope/range  of  systems  and  operations,  level  of 
integration,  sophistication,  complexity,  efficiency  and  effectiveness),  in  regards  to: 

a)  data  management 

b)  how  data  items  are  related  to  each  other 

c)  the  file  structure/data  structure  utilized  by  the  software  system 

d)  the  organization,  coherence,  linkage  and  unity  of  the  various  constituent 
system  elements 

e)  handling  the  large  number  and  numerous  types  of  transactions 

f)  the  capabilities  and  means  of  identifying,  scheduling  and  producing 
transactions,  events  and  activities  on  very  flexible  schedules,  e.g.,  the 
production  of  the  same  notice  type  on  a  daily  basis  at  various  quantity  levels 
specified  by  the  City 

g)  those  elements  of  a  proposer's  PVPMISS  that  actually  execute  actions  and 
events,  and 

h)  ease  of  modification  and  enhancement; 

are  clearly  and  comprehensively  detailed,  explained  and  documented  and  are 
determined  to  provide  an  efficient  and  effective  multi-application,  INTEGRATED 
set  of  systems,  subsystems,  system  elements  and  collection  of  data  —  and  are 
determined  to  accommodate  the  efficient  and  effective  development  and 
implementation  of  new  applications,  and  modification  or  expansion  of  existing 
applications,  in  such  a  manner  as  would  eliminate  or  extremely  minimize  any  risk 
to  the  quality  of  performance  or  operation  of  existing  applications  and  functions. 
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CRITERION  #  2: 
COMPLIANCE  WITH  SCOPE  OF  SERVICES 


NOT  ADVANTAGEOUS: 


1  The  proposer's  response  provides  details,  documentation,  explanations  and 
descriptions,  etc.  relative  to  RFP  requirements  that  are  only  marginally  or 
inconsistently  thorough,  comprehensive,  detailed  and  specific  —  and/or  are  only 
marginally  over  and  beyond  the  substantial  detail  provided  in  the  RFP  so  that  the 
features  and  benefits  of  the  proposer's  PVPMISS  could  not  be  adequately  ascertained 
—  and/or  the  content  of  said  response,  details,  documentation,  explanations  and 
descriptions,  etc.  provides  a  determination  that  the  proposer  possesses  proficiency, 
knowledge,  skills,  abilities,  expertise  and  resources  that  are  only  marginally 
commensurate  with  the  City's  extremely  high  expectations  and  demands  for  its 
PVPMISS. 


2  The  proposer's  substantiation  and  demonstration  of  it's  ability  to  comply  with  the 
RFP  effective  date  requirement  for  the  systems,  subsystems  and  services  is  only 
marginal  —  and/or  the  proposer's  compliance  would  be  contingent  upon  conditions  or 
alternatives  that  were  determined  to  pose  an  undue  risk  or  potential  for  disruption  to 
the  City's  current  level  of  PVPMISS  activities,  services  or  revenue  —  or  to  the 
objectives  of  this  RFP,  particularly  in  terms  of  timetable  or  the  provision  and 
operation  of  efficient  and  effective  system  and  service  features  and  functionality. 


3  The  proposer  documents,  substantiates  and  demonstrates  only  marginal  levels  of 
compliance  with  the  City's  requirements  and  performance  specifications  for  systems, 
subsystems  and  services  and  to  deliver,  provide  and  operate  systems,  subsystems  and 
services  that  would  be  beneficial  to  the  City  in  terms  such  as  functionality,  utility, 
efficiency  and  effectiveness  -  and/or  the  proposer  documents,  substantiates  and 
demonstrates  varying  or  inconsistent  levels  of  compliance  that  results  in  an  overall 
determination  of  only  marginal  compliance  with  the  City's  requirements  and 
performance  specifications  for  systems,  subsystems  and  services  and  to  deliver, 
provide  and  operate  systems,  subsystems  and  services  that  would  be  beneficial  to  the 
City  in  terms  such  as  functionality,  utility,  efficiency  and  effectiveness. 


4  The  proposer's  details,  explanations  or  real-life  (hard-copy)  illustrations  of  its  on-line 
information  system  are  sufficiently  unclear  or  lack  details  required  to  adequately 
assess  compliance  above  a  marginal  level  with  the  City's  data  and  information 
requirements  —  and/or  the  proposer's  explanations  or  real-life  (hard-copy) 
illustrations  of  it's  on-line  information  system  are  only  marginal  in  regards  to 
complying  or  in  the  ability  of  the  system  to  efficiently  and  effectively  be  modified  to 
accommodate  and  comply  with  the  City's  data  and  informational  requirements  for 
systems,  subsystems  and  services. 


144 


CRITERION  #  2: 
COMPLIANCE  WITH  SCOPE  OF  SERVICES 

NOT  ADVANTAGEOUS:  (continued) 


5  The  proposer's  explanations  or  real-life  (hard-copy)  illustrations  of  its  on-line 
information  system  are  sufficiently  unclear  or  lack  details  required  to  adequately 
assess  the  efficiency  and  effectiveness  of  the  proposer's  on-line  information  system 
above  a  marginal  level  (in  terms  such  as  public  responsiveness/customer  service, 
ease  of  access,  scrolling,  organization  and  consolidation  of  data,  integration  of  data, 
format  and  user-friendliness)  —  and/or  the  proposer's  on-line  information  system  is 
determined  to  be  only  marginally  efficient  and  effective  for  RFP  required  systems, 
subsystems  and  services  in  terms  such  as  public  responsiveness/customer  service, 
ease  of  access,  scrolling,  organization  and  consolidation  of  data,  integration  of  data, 
format  and  user-friendliness. 


6  The  proposer's  documentation,  substantiation  and  demonstration  of  its  quality  control 
of  data  is  sufficiently  unclear  or  lacks  details  to  adequately  assess  this  area  above  a 
marginal  level  —  and/or,  the  content  of  its  explanations  is  determined  to  pose  an 
undue  risk  or  potential  for  disruption  to  the  City's  objectives  to  optimize 
data/information  integrity  and  accurate  processing. 


7  The  features  and  functionality  of  the  proposer's  systems,  subsystems  and  services 
provide  only  a  marginal  level  of  assurance  that  the  City's  relevant  operational  costs 
(in  terms  such  as  staffing  levels,  operational  efficiencies,  level  of  required  oversight) 
would  not  be  increased  and  would  be  effectively  minimized  or  reduced. 


8  The  credibility  of  the  proposer's  RFP  responses  in  terms  of  demonstrated  capability 
to  comply  with  specified  requirements  throughout  the  full  term  of  the  proposed 
contract  is  determined  to  be  only  marginal. 


9  The  proposer  provides  an  undue  risk  or  potential  for  disruption  to  the  City's 
objectives  to  move  forward  on  July  1,  2010,  (and  throughout  the  full  term  of  the 
proposed  contract)  with  the  continued  generation,  development  and  implementation 
of  on-going  enhancements  and  improvements  to  systems,  system  elements  and 
services. 


145 


CRITERION  #  2: 
COMPLIANCE  WITH  SCOPE  OF  SERVICES 
NOT  ADVANTAGEOUS:  (continued) 


10  The  structural  and  data  management  design  and  approach  and  software(including 
Data  Base  Management  System  [DBMS],  if  applicable)  of  the  proposer's  PVPMISS 
(in  terms  such  as  size,  volumes,  scope/range  of  systems  and  operations,  level  of 
integration,  sophistication,  complexity,  efficiency  and  effectiveness),  in  regards  to: 

a)  data  management 

b)  how  data  items  are  related  to  each  other 

c)  the  file  structure/data  structure  utilized  by  the  software  system 

d)  the  organization,  coherence,  linkage  and  unity  of  the  various  constituent  system 

elements 

e)  handling  the  large  number  and  numerous  types  of  transactions 

f)  the  capabilities  and  means  of  identifying,  scheduling  and  producing  transactions, 

events  and  activities  on  very  flexible  schedules,  e.g.,  the  production  of  the  same 
notice  type  on  a  daily  basis  at  various  quantity  levels  specified  by  the  City 

g)  those  elements  of  a  proposer's  PVPMISS  that  actually  execute  actions  and  events, 

and 

h)  ease  of  modification  and  enhancement; 

are  only  marginally  explained  and  documented  (in  terms  of  level  of  detail,  clarity  or 
and  comprehensiveness)  so  that  the  features  and  benefits  of  the  proposer's  design  and 
approach  could  not  be  adequately  assessed;  and/or,  are  determined  to  provide  only  a 
marginally  efficient  or  effective  multi-application,  INTEGRATED  set  of  systems, 
subsystems,  system  elements  and  collection  of  data  —  or  are  determined  to 
accommodate  only  a  marginally  efficient  or  effective  development  and 
implementation  of  new  applications,  or  modification  or  expansion  of  existing 
applications,  in  such  a  manner  as  would  provide  undue  risk  to  the  quality  of 
performance  or  operation  of  existing  applications  and  functions. 
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CRITERION  #  2: 
COMPLIANCE  WITH  SCOPE  OF  SERVICES 

UNACCEPTABLE: 


1  The  proposer's  response  provides  details,  documentation,  explanations  and 
descriptions,  etc.  relative  to  the  RFP  requirements  that  are  deficient  in  terms  of 
comprehensiveness,  detail  or  specificity  —  and/or  substantially  repeats,  paraphrases 
or  reinterprets  RFP  wording  without  providing  independent  explanations  so  as  to 
provide  a  negative  assessment  of  the  features  and  benefits  of  the  proposer's 
PVPMISS  —  and/or  the  content  of  said  explanations  and  descriptions  provides  a 
substantial  level  of  doubt  that  the  proposer  possesses  the  proficiency,  knowledge, 
skills,  abilities,  expertise  and  resources  commensurate  with  the  City's  extremely  high 
expectations  and  demands  for  its  PVPMISS. 


2  The  proposer's  substantiation  and  demonstration  of  its  ability  to  meet  the  RFP 
effective  date  requirement  for  the  systems,  subsystems  and  services  is  deficient  — 
and/or,  the  proposer's  compliance  would  be  contingent  upon  conditions  or 
alternatives  that  were  determined  to  pose  a  substantial  risk  or  potential  for  disruption 
to  the  City's  current  level  of  PVPMISS  activities,  services  and  revenue,  or  to  the 
major  objectives  of  this  RFP,  particularly  in  terms  of  timetable  or  the  provision  and 
operation  of  efficient  and  effective  system  and  service  features  and  functionality. 


3  The  proposer's  level  of  compliance  with  the  City's  requirements  and  performance 
specifications  for  systems,  subsystems  and  services  and  to  deliver,  provide  and 
operate  systems,  subsystems  and  services  that  would  be  beneficial  to  the  City  in 
terms  such  as  functionality,  utility,  efficiency  and  effectiveness  is  deficient  —  and/or 
the  proposer  documents,  substantiates  and  demonstrates  varying  or  inconsistent 
levels  of  compliance  that  results  overall  in  a  determination  of  deficient  compliance 
with  the  City's  requirements  and  performance  specifications  for  systems,  subsystems 
and  services  and  to  deliver,  provide  and  operate  systems,  subsystems  and  services 
that  would  be  beneficial  to  the  City  in  terms  such  as  functionality,  utility,  efficiency 
and  effectiveness. 


4  The  proposer  provides  a  generally  deficient  level  of  detailed  and  comprehensive 
explanations  or  real-life  (hard-copy)  illustrations  of  its  on-line  information  system 
for  systems,  subsystems  and  services  —  and/or  the  proposer's  explanations  or  real- 
life  (hard-copy)  illustrations  of  its  on-line  information  system  are  deficient  in  regards 
to  complying  or  in  the  ability  of  the  system  to  efficiently  and  effectively  be  modified 
to  accommodate  and  comply  with  the  City's  data  and  informational  requirements  for 
systems,  subsystems  or  services. 
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CRITERION  #  2: 
COMPLIANCE  WITH  SCOPE  OF  SERVICES 

UNACCEPTABLE:  (continued) 


5  The  efficiency  and  effectiveness  of  the  proposer's  on-line  information  system  (in 
terms  such  as  public  responsiveness/customer  service,  ease  of  access,  scrolling, 
organization  and  consolidation  of  data,  integration  of  data,  format  and  user- 
friendliness)  is  determined  to  be  negative  due  to  the  provision  of  deficiently  detailed 
or  comprehensive  explanations  or  real-life  (hard-copy)  illustrations  —  and/or  the 
proposer's  on-line  information  system  is  determined  to  be  deficient  in  regards  to 
efficiency  and  effectiveness  for  RFP  required  systems,  subsystems  or  services  in 
terms  such  as  public  responsiveness/  customer  service,  ease  of  access,  scrolling, 
organization  and  consolidation  of  data,  integration  of  data,  format  and  user- 
friendliness. 


6  The  proposer's  documentation,  substantiation  and  demonstration  of  its  quality  control 
of  data  is  deficient  -  and/or,  the  content  of  its  explanations  is  determined  to  pose 
substantial  risk  or  potential  for  disruption  to  the  City's  objectives  to  optimize 
data/information  integrity.. 


7  The  features  and  functionality  of  the  proposer's  systems,  subsystems  or  services 
provides  a  substantial  level  of  doubt  that  the  City's  relevant  operational  costs  (in 
terms  such  as  staffing  levels,  operational  efficiencies,  level  of  required  oversight) 
would  not  be  increased  and  would  be  effectively  minimized  or  reduced. 


8  The  credibility  of  the  proposer's  RFP  responses  in  terms  of  demonstrated  capability 
to  comply  with  specified  requirements  throughout  the  full  term  of  the  proposed 
contract  is  determined  to  be  deficient. 


9  The  proposer  provides  substantial  risk  or  potential  for  disruption  to  the  City's 
objective  to  move  forward  on  July  1,  2010,  (and  throughout  the  full  term  of  the 
proposed  contract)  with  the  continued  generation,  development  and  implementation 
of  on-going  enhancements  and  improvements  to  systems,  system  elements  and 
services. 
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CRITERION  #  2: 
COMPLIANCE  WITH  SCOPE  OF  SERVICES 


UNACCEPTABLE:  (continued) 


10  The  structural  and  data  management  design  and  approach  and  software(including 
Data  Base  Management  System  [DBMS],  if  applicable)  of  the  proposer's  PVPMISS 
(in  terms  such  as  size,  volumes,  scope/range  of  systems  and  operations,  level  of 
integration,  sophistication,  complexity,  efficiency  and  effectiveness),  in  regards  to: 

a)  data  management 

b)  how  data  items  are  related  to  each  other 

c)  the  file  structure/data  structure  utilized  by  the  software  system 

d)  the  organization,  coherence,  linkage  and  unity  of  the  various  constituent  system 
elements 

e)  handling  the  large  number  and  numerous  types  of  transactions 

f)  the  capabilities  and  means  of  identifying,  scheduling  and  producing  transactions, 
events  and  activities  on  very  flexible  schedules,  e.g.,  the  production  of  the  same 
notice  type  on  a  daily  basis  at  various  quantity  levels  specified  by  the  City 

g)  those  elements  of  a  proposer's  PVPMISS  that  actually  execute  actions  and  events, 
and 

h)  ease  of  modification  and  enhancement; 


are  deficiently  explained  and  documented  (in  terms  of  level  of  detail,  clarity  or  and 
comprehensiveness)  so  as  to  provide  a  negative  assessment  of  the  features  and 
benefits  of  the  proposer's  design  and  approach;  and/or,  are  determined  to  provide  an 
inefficient  or  ineffective  multi-application,  INTEGRATED  set  of  systems, 
subsystems,  system  elements  and  collection  of  data  -  or  are  determined  to 
accommodate  the  inefficient  or  ineffective  development  and  implementation  of  new 
applications,  or  modification  or  expansion  of  existing  applications,  in  such  a  manner 
as  would  provide  substantial  risk  or  potential  for  disruption  to  the  quality  of 
performance  or  operation  of  existing  applications  and  functions. 
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(7.3)  COMPARATIVE  CRITERION  #  3: 


OPERATION/MANAGEMENT  PLAN  AND  PLAN  OF  SERVICES  AND 
PERSONNEL  DEPTH,  QUALIFICATIONS,  EXPERIENCE 
AND  PERFORMANCE 
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CRITERION  #3: 

OPERATION/MANAGEMENT  PLAN  AND  PLAN  OF  SERVICES  AND 
PERSONNEL  DEPTH,  QUALIFICATIONS,  EXPERIENCE 
AND  PERFORMANCE 

HIGHLY  ADVANTAGEOUS: 

1  The  Prime  Vendor  has  a  minimum  of  five  (5)  years  direct  experience  in  PVPMISS 
installations  similar,  comparable  and  analogous  to  Boston's,  of  which  a  minimum 
of  three  (3)  years  experience  is  within  the  time  period  July  1,  2004  through  July  1, 
2009. 

2  The  proposer  has  clearly  and  comprehensively  detailed,  described  and  substantiated 
its  ability  to  provide  an  extremely  efficient,  effective  and  viable  single-point-of- 
contract  role  and  responsibility  where  the  Prime  Vendor  will  be  directly 
overseeing,  managing,  administering  and  quality  controlling  the  complete 
PVPMISS,  and  further,  will  be  directly  providing  primary  EDP  systems  and 
subsystems  (e.g.  database  management  system,  all  on-line  systems)  and  directly 
providing  and  performing  and/or  providing  via  experienced  and  qualified 
secondary  vendors  other  services  and  functions  (e.g.  data  entry,  microfilming, 
lockbox  processing,  mail  house  processing)  in  a  highly  viable,  cohesive  and 
effective  manner;  and  in  further  regards  to  any  requirements  performed  and 
provided  via  secondary  vendors,  the  response  clearly  and  comprehensively  details, 
describes  and  substantiates,  for  an  optimally  efficient,  effective  and  viable  single- 
point-of-contract  responsibility,  the  relationship  between  the  Prime  Vendor  and 
secondary  vendors  and  any  and  all  approaches  and  steps  that  will  be  taken  to 
oversee  and  quality  control  the  work  product  and  other  duties  and  responsibilities 
of  the  secondary  vendor;  and  moreover,  the  Prime  Vendor  has  extensively 
demonstrated  and  proven  its  ability  to  provide  efficient  and  effective  similar  single- 
point-of-contract  roles  and  responsibilities  to  its  other  PVPMISS  installations 
which  are  similar  and  comparable  to  Boston. 

3  The  response  has  clearly  and  comprehensively  detailed,  and  described  as  well  as 
substantiated  the  ability  to  provide  a  specific  Boston  Office  organization  that  will 
provide  the  highest  level  of  assurance  that  the  proposer's  contract  management  plan 
and  service  plan  is  extremely  effective,  efficient  and  viable  and  will  provide  the 
proposer  with  the  ability  to  very  efficiently  and  effectively  comply  with  the  Scope 
of  Services  of  the  RFP;  and  moreover,  the  proposer  has  extensively  demonstrated 
and  proven  its  ability  to  provide  similar  organizational  resources  and  structures  that 
comprise  a  Local  PVPMISS  Office  to  its  other  PVPMISS  installations  which  are 
similar  and  comparable  to  Boston. 

4  The  response  has  clearly  and  comprehensively  detailed,  and  described  as  well  as 
substantiated  the  ability  to  provide  a  specific  Data  Center/'Head  Office' 
organization  that  will  provide  the  highest  level  of  assurance  that  the  proposer's 
contract  management  plan  and  service  plan  is  extremely  effective,  efficient  and 
viable,  and  will  provide  the  proposer  with  the  ability  to  very  efficiently  and 
effectively  complete  the  Scope  of  Services  of  the  RFP,  and  moreover,  the  Proposer 
has  extensively  demonstrated  and  proven  its  ability  to  provide  similar 
organizational  resources  and  structures  that  comprise  a  Data  Center/"Head  Office 
to  its  other  PVPMISS  installations  which  are  similar  and  comparable  to  Boston. 
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CRITERION  #3: 

OPERATION/MANAGEMENT  PLAN  AND  PLAN  OF  SERVICES  AND 
PERSONNEL  DEPTH,  QUALIFICATIONS,  EXPERIENCE 
AND  PERFORMANCE 

HIGHLY  ADVANTAGEOUS: (cont.) 


5     The  authority  of  the  company  staff  directly  involved  in  the  proposed  Boston 
contract  (in  particular  the  Boston  Office,  Boston  PVPMISS  Project  Manager,  the 
Data  Center  Boston  PVPMISS  Project  Manager  and  key  management,  technical 
and  administrative  managers  directly  involved  with  the  Boston  PVPMISS  contract) 
and  these  persons'  position  in  the  company/corporate  hierarchy,  in  addition  to  their 
reporting  relationships  with  the  higher  echelon  of  management,  is  explained  in 
detail  and  provides  the  highest  level  of  assurance  that  the  project  team's  command 
of  company/corporate  resources  is  sufficient  so  as  to  complete  successfully, 
efficiently  and  effectively  the  scope  of  the  RFP  and  to  optimally  respond  to 
problems  and  changing  conditions. 


6    The  proposer  clearly  and  specifically  has  committed  and  identified  an  adequate 
group  (in  terms  of  numbers,  quality  and  diversity)  of  extensively  experienced 
PVPMISS  Boston-located  and  non-Boston-located  Key  Personnel  who  would  be 
required  to  provide,  operate  and  enhance  Boston's  PVPMISS  with  the  highest  level 
of  effectiveness  and  efficiency.  (Key  Personnel  include  full-time  and  part-time, 
Prime  Vendor  and  secondary  vendors  (if  any)  management,  administrative, 
supervisory,  technical,  project  management,  systems  analyst,  programmer, 
operational,  production,  quality  control  specialist  and  any  other  staff  who  actually 
have  significant  responsibility  in  specific  or  general  areas  of  importance  to 
providing,  operating  and  enhancing  Boston's  PVPMISS.) 


7    All  or  virtually  all  of  the  Key  Personnel  are  proven  to  possess  a  very  high  level  of 
actual  and  direct  PVPMISS  experience  and  past  performance  in  PVPMISS 
operating  installations  similar  to  Boston's  in  terms  of  complexity,  volumes,  types  of 
transactions,  scope  /  range  of  systems  and  operations,  and  other  RFP  requirements. 


8     The  proposer  has  provided  the  highest  level  of  assurance  that  the  specifically 
committed  Key  Personnel  can  reasonably  be  expected  to  be  provided  in  terms  of 
the  proposer's  depth  of  PVPMISS  personnel  and  ongoing/planned  PVPMISS  and 
other  contractual  commitments  in  other  municipalities,  locations  and  installations. 


9     The  proposer  has  provided  the  highest  level  of  assurance  that  it  is  capable  of 
effectively  providing,  operating  and  enhancing  the  Boston  PVPMISS  with  other 
Key  Personnel  in  cases  of  staff  turnover  or  an  increase  /  surge  in  projects  of  the 
introduction  of  problems  caused  by  changing  conditions. 
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CRITERION  #3: 

OPERATION/MANAGEMENT  PLAN  AND  PLAN  OF  SERVICES  AND 
PERSONNEL  DEPTH,  QUALIFICATIONS,  EXPERIENCE 
AND  PERFORMANCE 

HIGHLY  ADVANTAGEOUS: (cont.) 


10  The  proposer  clearly  and  specifically  has  committed  an  adequate  group  in  terms  of 
numbers,  quality  and  diversity  of  Boston-based  and  non-Boston-based  Support 
Personnel  that  would  be  required  to  provide  and  operate  Boston's  PVPMISS  with 
optimal  effectiveness  and  efficiency.  (Support  Personnel  include  support,  clerical 
and  technical  staff  for  areas  that  include,  but  are  not  limited  to,  front-end 
processing,  ticket  data  input,  transactions  update,  lock-box  operations,  payment 
processing,  processing  and  revenue  controls,  scheduling  and  controls,  quality 
assurance,  vendor  billing,  notice  generation  and  mailing,  computer  operations, 
telecommunications  operations  and  equipment  maintenance.) 


11  The  effectiveness  and  efficiency  of  the  proposer's  project  organization  and  the 
quality  and  depth  of  the  proposer's  PVPMISS  personnel  provides  the  highest  level 
of  assurance  that  the  City's  relevant  operational  costs  would  be  optimally 
minimized  or  reduced  or  would  not  increase. 


12  The  effectiveness  and  efficiency  of  the  proposer's  project  organization  and  the 
quality  and  depth  of  the  proposer's  PVPMISS  personnel  provides  the  highest  level 
of  assurance  that  the  City  would  have  the  ability  to  move  forward  on  July  1,  2010, 
(and  throughout  the  full  term  of  the  proposed  contract)  with  the  development  and 
implementation  of  on-going  enhancements  and  improvements  in  public 
responsiveness  and  customer  service,  continued  generation  of  operational 
efficiencies  and  increased  revenues. 


13  The  physical  location  of  critical  facilities  and  personnel,  not  including  the  main 
Data  Center,  are  sited  for  the  most  part  in  proximity  (close)  to  City  Hall  so  that  City 
employees  particularly  involved  with  this  contract  and  located  at  City  Hall  can 
easily  and  conveniently,  from  a  time  and  distance  perspective,  inspect,  monitor, 
quality  control,  access,  communicate  and  conduct  face  to  face  meetings,  etc.  on  a 
routine  and  ad  hoc  basis  as  needed.  The  evaluation  will  be  based  on  an  overall 
assessment  of  the  locations  of  personnel  and  facilities.  However,  in  general,  to 
qualify  for  a  Highly  Advantageous  rating,  the  Boston  Project  Manager  and  other 
key  local  systems  personnel  shall  be  located  within  approximately  1  (one)  mile  of 
City  Hall;  the  mail  sorting  operation,  the  Lockbox  and  the  Ticket  Data  Entry 
facilities  shall  be  located  within  approximately  3  (three)  miles  of  City  Hall;  a  Prime 
Vendor  PVPMISS  administrative/management  office  shall  be  located  within 
approximately  3  (three)  miles  of  City  Hall. 
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CRITERION  #3: 

OPERATION/MANAGEMENT  PLAN  AND  PLAN  OF  SERVICES  AND 
PERSONNEL  DEPTH,  QUALIFICATIONS,  EXPERIENCE 
AND  PERFORMANCE 

HIGHLY  ADVANTAGEOUS: (cont.) 


The  proposer  has  identified  experienced  and  knowledgeable  Parking  and 
Transportation  Management  Personnel  who  would  be  available  for  occasional 
assistance  with  a  variety  of  PVPMISS  related  assignments  such  as  fine  structure 
analysis,  route  analysis,  organizational  structures  and  staffing  patterns,  enforcement 
strategies,  etc.,  vis-a-vis  that  personnel's  perspective,  knowledge  and  expertise  of 
parking  and  transportation  operations. 
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CRITERION  #3: 

OPERATION/MANAGEMENT  PLAN  AND  PLAN  OF  SERVICES  AND 
PERSONNEL  DEPTH,  QUALIFICATIONS,  EXPERIENCE  AND 

PERFORMANCE 

ADVANTAGEOUS: 


The  Prime  Vendor  has  a  minimum  of  three  (3)  years  of  direct  experience  in 
PVPMISS  installations  similar,  comparable  and  analogous  to  Boston's,  of  which 
two  (2)  years  is  within  the  time  period  July  1,  2005  through  July  1,  2009. 


The  proposer  has  clearly  and  comprehensively  detailed,  described  and  substantiated 
its  ability  to  provide  an  efficient,  effective  and  viable  single-point-of-contract  role 
and  responsibility  where  the  Prime  Vendor  will  be  directly  overseeing,  managing, 
administering  and  quality  controlling  the  complete  PVPMISS,  and  further,  will  be 
directly  providing  primary  EDP  systems  and  subsystems  (e.g.  database 
management  system,  all  on-line  systems)  and  directly  providing  and  performing 
and/or  providing  via  experienced  and  qualified  secondary  vendors  other  services 
and  functions  (e.g.  data  entry,  microfilming,  lockbox  processing,  mail  house 
processing)  in  a  highly  viable,  cohesive  and  effective  manner;  and  in  further 
regards  to  any  requirements  performed  and  provided  via  secondary  vendors,  the 
response  clearly  and  comprehensively  details,  describes  and  substantiates,  for  an 
efficient,  effective  and  viable  single-point-of-contract  responsibility,  the 
relationship  between  the  Prime  Vendor  and  secondary  vendors  and  any  and  all 
approaches  and  steps  that  will  be  taken  to  oversee  and  quality  control  the  work 
product  and  other  duties  and  responsibilities  of  the  secondary  vendor;  and 
moreover,  the  Prime  Vendor  has  adequately  demonstrated  and  proven  its  ability  to 
provide  efficient  and  effective  similar  single-point-of-contract  roles  and 
responsibilities  to  its  other  PVPMISS  installations  which  are  similar  and 
comparable  to  Boston. 


The  response  has  detailed,  and  described  as  well  as  substantiated  the  ability  to 
provide  a  Specific  Boston  Office  organization  that  will  provide  a  high  level  of 
assurance  that  the  proposer's  contract  management  plan  and  service  plan  is 
effective,  efficient  and  viable  and  will  provide  the  proposer  with  the  ability  to 
efficiently  and  effectively  comply  with  the  Scope  of  Services  of  the  RFP;  and 
moreover,  the  proposer  has  adequately  demonstrated  and  proven  its  ability  to 
provide  similar  organizational  resources  and  structures  that  comprise  a  Local 
PVPMISS  Office  to  its  other  PVPMISS  installations  which  are  similar  and 
comparable  to  Boston. 


The  response  has  clearly  and  comprehensively  detailed,  and  described  as  well  as 
substantiated  the  ability  to  provide  a  specific  Data  Center/'Head  Office' 
organization  that  will  provide  a  high  level  of  assurance  that  the  proposer's  contract 
management  plan  and  service  plan  is  effective,  efficient  and  viable,  and  will 
provide  the  proposer  with  the  ability  to  efficiently  and  effectively  complete  the 
Scope  of  Services  of  the  RFP,  and  moreover,  the  proposer  has  adequately 
demonstrated  and  proven  its  ability  to  provide  similar  organizational  resources  and 
structures  that  comprise  a  Data  Center/'Head  Office'  to  its  other  PVPMISS 
installations  which  are  similar  and  comparable  to  Boston. 
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CRITERION  #3: 

OPERATION/MANAGEMENT  PLAN  AND  PLAN  OF  SERVICES  AND 
PERSONNEL  DEPTH,  QUALIFICATIONS,  EXPERIENCE  AND 

PERFORMANCE 

ADVANTAGEOUS:  (cont.) 


5     The  authority  of  the  company  staff  directly  involved  in  the  proposed  Boston 
contract  (in  particular  the  Boston  Office,  Boston  PVPMISS  Project  Manager,  the 
Data  Center  Boston  PVPMISS  Project  Manager  and  key  management,  technical 
and  administrative  managers  directly  involved  with  the  Boston  PVPMISS  contract) 
and  these  persons'  position  in  the  company/corporate  hierarchy,  in  addition  to  their 
reporting  relationships  with  the  higher  echelon  of  management,  is  explained  in 
detail  and  provides  a  high  level  of  assurance  that  the  project  team's  command  of 
company/corporate  resources  is  sufficient  so  as  to  complete  successfully,  efficiently 
and  effectively  the  scope  of  the  RFP  and  to  optimally  respond  to  problems  and 
changing  conditions. 


6    The  proposer  has  clearly  and  specifically  committed  and  identified  an  adequate 
group  (in  terms  of  numbers,  quality  and  diversity)  of  experienced  PVPMISS 
Boston-located  and  non-Boston-located  Key  Personnel  that  would  be  required  to 
provide,  operate  and  enhance  Boston's  PVPMISS  with  a  high  level  of  effectiveness 
and  efficiency. 


7    A  very  extensive  number  of  the  Key  Personnel  are  proven  to  possess  a  high  level  of 
actual  and  direct  PVPMISS  experience  and  past  performance  in  PVPMISS 
operating  installations  similar  to  Boston's  in  terms  of  complexity,  volumes,  types  of 
transactions,  scope  /  range  of  systems  and  operations,  and  other  RFP  requirements. 


8     The  proposer  has  provided  a  high  level  of  assurance  that  the  specifically  committed 
Key  Personnel  can  reasonably  be  expected  to  be  provided  in  terms  of  the  proposer's 
depth  of  PVPMISS  personnel  and  ongoing/planned  PVPMISS  and  other 
contractual  commitments  in  other  municipalities,  locations  and  installations. 


9     The  proposer  has  provided  a  high  level  of  assurance  that  it  is  capable  of  effectively 
providing  ,  operating  and  enhancing  the  Boston  PVPMISS  with  other  Key 
Personnel  in  cases  of  staff  turnover  or  an  increase  /  surge  in  projects  of  the 
introduction  of  problems  caused  by  changing  conditions. 


10  The  proposer  has  clearly  and  specifically  committed  an  adequate  group  in  terms  of 
numbers,  quality  and  diversity  of  Boston-based  and  non-Boston-based  Support 
Personnel  that  would  be  required  to  provide  and  operate  Boston's  PVPMISS  with  a 
high  level  of  effectiveness  and  efficiency. 
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CRITERION  #3: 

OPERATION/MANAGEMENT  PLAN  AND  PLAN  OF  SERVICES  AND 
PERSONNEL  DEPTH,  QUALIFICATIONS,  EXPERIENCE 
AND  PERFORMANCE 

ADVANTAGEOUS:  (cont.) 


11  The  effectiveness  and  efficiency  of  the  proposer's  project  organization  and  the 
quality  and  depth  of  the  proposer's  PVPMISS  personnel  provides  a  high  level 
assurance  that  the  City's  relevant  operational  costs  would  be  optimally  minimized 
or  reduced  or  would  not  increase. 


12  The  effectiveness  and  efficiency  of  the  proposer's  project  organization  and  the 
quality  and  depth  of  the  proposer's  PVPMISS  personnel  provides  a  high  level  of 
assurance  that  the  City  would  have  the  ability  to  move  forward  on  July  1,  2010, 
(and  throughout  the  full  term  of  the  proposed  contract)  with  the  development  and 
implementation  of  on-going  enhancements  and  improvements  public 
responsiveness  and  customer  service,  continued  generation  of  operational 
efficiencies  and  increased  revenue. 


13  The  physical  location  of  critical  facilities  and  personnel,  not  including  the  main 
Data  Center,  are  sited  for  the  most  part  in  proximity  (close)  to  City  Hall  so  that  City 
employees  particularly  involved  with  this  contract  and  located  at  City  Hall  can 
easily  and  conveniently,  from  a  time  and  distance  perspective,  inspect,  monitor, 
quality  control,  access,  communicate  and  conduct  face  to  face  meetings,  etc.  on  a 
routine  and  ad  hoc  basis  as  needed.  The  evaluation  will  be  based  on  an  overall 
assessment  of  the  locations  of  personnel  and  facilities.  However,  in  general,  to 
qualify  for  an  Advantageous  rating,  the  Boston  Project  Manager  and  other  key  local 
systems  personnel  shall  be  located  within  approximately  1  (one  )  and  2  (two)  miles 
of  City  Hall;  the  mail  sorting  operation,  the  Lockbox  and  the  Ticket  Data  Entry 
facilities  shall  be  located  within  approximately  3  (three)  and  5  (five)  miles  of  City 
Hall;  a  Prime  Vendor  PVPMISS  administrative/management  office  shall  be  located 
within  approximately  3  (three)  and  5  (five)  miles  of  City  Hall. 


14  The  proposer  has  identified  experienced  and  knowledgeable  Parking  and 
Transportation  Management  Personnel  who  would  be  available  for  occasional 
assistance  with  a  variety  of  PVPMISS  related  assignments  such  as  fine  structure 
analysis,  route  analysis,  organizational  structures  and  staffing  patterns,  enforcement 
strategies,  etc.,  vis-a-vis  that  personnel's  perspective,  knowledge  and  expertise  of 
parking  and  transportation  operations. 
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CRITERION  #3: 

OPERATION/MANAGEMENT  PLAN  AND  PLAN  OF  SERVICES  AND 
PERSONNEL  DEPTH,  QUALIFICATIONS,  EXPERIENCE 
AND  PERFORMANCE 

NOT  ADVANTAGEOUS: 


The  Prime  Vendor  has  less  than  three  (3)  years  direct  experience  in  PVPMISS 
installations  similar,  comparable  and  analogous  to  Boston's,  and/or  less  than  two 
(2)  years  experience  is  within  the  time  period  July  1,  2005  through  July  1,  2009. 


The  proposer  has  detailed,  described  and  substantiated  its  ability  to  provide  only  a 
marginally  efficient,  effective  and  viable  single-point-of-contract  role  and 
responsibility  where  the  Prime  Vendor  will  be  directly  overseeing,  managing, 
administering  and  quality  controlling  the  complete  PVPMISS,  and  further,  will  be 
directly  providing  primary  EDP  systems  and  subsystems  (e.g.  database 
management  system,  all  on-line  systems)  and  directly  providing  and  performing 
and/or  providing  via  secondary  vendors  other  services  and  functions  (e.g.  data 
entry,  microfilming,  lockbox  processing,  mail  house  processing)  in  a  viable, 
cohesive  and  effective  manner;  and/or,  in  further  regards  to  any  requirements 
performed  and  provided  via  secondary  vendors,  the  response  details,  describes  and 
substantiates,  for  only  a  marginally  efficient,  effective  and  viable  single-point-of- 
contract  responsibility,  the  relationship  between  the  Prime  Vendor  and  secondary 
vendors  and  any  and  all  approaches  and  steps  that  will  be  taken  to  oversee  and 
quality  control  the  work  product  and  other  duties  and  responsibilities  of  the 
secondary  vendor;  and/or,  the  Prime  Vendor  has  only  marginally  demonstrated  and 
proven  its  ability  to  provide  efficient  and  effective  similar  single-point-of- 
contract  roles  and  responsibilities  to  its  other  PVPMISS  installations  which  are 
similar  and  comparable  to  Boston. 


The  response  has  detailed,  and  described  as  well  as  substantiated  the  ability  to 
provide  a  specific  Boston  Office  organization  that  will  provide  only  a  marginal 
level  of  assurance  that  the  proposer's  contract  management  plan  and  service  plan  is 
effective,  efficient  and  viable  and  will  provide  the  proposer  with  the  ability  to 
efficiently  and  effectively  comply  with  the  Scope  of  Services  of  the  RFP;  and/or, 
the  proposer  has  only  marginally  demonstrated  and  proven  its  ability  to  provide 
similar  organizational  resources  and  structures  that  comprise  a  Local  PVPMISS 
Office  to  its  other  PVPMISS  installations  which  are  similar  and  comparable  to 
Boston. 


The  response  has  detailed,  and  described  as  well  as  substantiated  the  ability  to 
provide  a  specific  Data  Center/'Head  Office'  organization  that  will  provide  only  a 
marginal  level  of  assurance  that  the  proposer's  contract  management  plan  and 
service  plan  is  effective,  efficient  and  viable,  and  will  provide  the  proposer  with  the 
ability  to  efficiently  and  effectively  complete  the  Scope  of  Services  of  the  RFP, 
and/or,  the  Proposer  has  only  marginally  demonstrated  and  proven  its  ability  to 
provide  similar  organizational  resources  and  structures  that  comprise  a  Data 
Center/'Head  Office'  to  its  other  PVPMISS  installations  which  are  similar  and 
comparable  to  Boston. 
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CRITERION  #3: 

OPERATION/MANAGEMENT  PLAN  AND  PLAN  OF  SERVICES  AND 
PERSONNEL  DEPTH,  QUALIFICATIONS,  EXPERIENCE 
AND  PERFORMANCE 

NOT  ADVANTAGEOUS:  (cont.) 


5     The  authority  of  the  company  staff  directly  involved  in  the  proposed  Boston 
contract  (in  particular  the  Boston  Office,  Boston  PVPMISS  Project  Manager,  the 
Data  Center  Boston  PVPMISS  Project  Manager  and  key  management,  technical 
and  administrative  managers  directly  involved  with  the  Boston  PVPMISS  contract) 
and  these  persons'  position  in  the  company  /  corporate  hierarchy,  in  addition  to 
their  reporting  relationships  with  the  next  higher  echelon  of  management  is 
determined  to  provide  a  marginal  level  of  assurance  that  the  project  team's 
command  of  company  /  corporate  resources  is  sufficient  so  as  to  successfully 
complete  the  scope  of  the  RFP  and  to  adequately  respond  to  problems  and  changing 
conditions. 


6    The  proposer  has  committed  and  identified  a  marginally  acceptable  group  (in  terms 
of  numbers,  quality  and  diversity)  of  experienced  PVPMISS  Boston  located  and 
non-Boston  located  Key  Personnel  that  would  be  required  to  provide,  operate  and 
enhance  Boston's  PVPMISS  with  adequate  effectiveness  and  efficiency. 


7    A  marginally  acceptable  number  of  Key  Personnel  are  proven  to  possess  an 

adequate  level  of  actual  and  direct  PVPMISS  experience  and  past  performance  in 
PVPMISS  operating  environments  similar  to  Boston's  in  terms  of  complexity, 
volumes,  types  of  transactions,  scope/  range  of  systems  and  operations  and  other 
EDP  requirements. 


8     The  proposer  has  provided  a  marginal  level  of  assurance  that  the  specifically 
committed  Key  Personnel  can  reasonably  be  expected  to  be  provided  in  terms  of 
the  proposer's  depth  of  PVPMISS  personnel  and  on-going  planned  PVPMISS 
activity  and  other  contractual  commitments  in  other  municipalities  and 
installations. 


9     The  proposer  has  provided  a  marginal  level  of  assurance  that  it  is  capable  of 
effectively  providing,  operating  and  enhancing  the  Boston  PVPMISS  with  other 
Key  Personnel  in  cases  of  staff  turnover  or  an  increase  /  surge  in  projects  or  the 
introduction  of  problems  caused  by  changing  conditions. 


10  The  proposer  has  committed  a  marginally  acceptable  number  of  diverse  and 
qualified  Boston  based  and  non-Boston  based  Support  Personnel  that  would  be 
required  to  provide  and  operate  Boston's  PVPMISS  with  adequate  effectiveness 
and  efficiency. 
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CRITERION  #3: 

OPERATION/MANAGEMENT  PLAN  AND  PLAN  OF  SERVICES  AND 
PERSONNEL  DEPTH,  QUALIFICATIONS,  EXPERIENCE 
AND  PERFORMANCE 

NOT  ADVANTAGEOUS : (cont.) 


11  The  proposer's  project  organization  and  the  quality  and  depth  of  the  proposer's 
identified  Key  and  Support  PVPMISS  Personnel  provide  a  marginal  level  of 
assurance  that  the  City's  relevant  operational  costs  would  be  adequately  minimized 
or  reduced  or  would  not  increase. 


12  The  proposer's  project  organization  and  the  quality  and  depth  of  the  proposer's 
identified  Key  and  Support  PVPMISS  Personnel  provide  a  marginal  level  of 
assurance  that  the  City  would  have  the  ability  to  move  forward  on  July  1,  2010 
(and  throughout  the  full  term  of  the  proposed  contract)  with  the  development  and 
implementation  of  on-going  enhancements  and  improvements  in  public 
responsiveness  and  customer  service,  continued  generation  of  operational 
efficiencies  and  increased  revenues. 


13  The  physical  location  of  critical  facilities  and  personnel,  not  including  the  main 
Data  Center,  are  sited  only  marginally,  for  the  most  part,  in  proximity  (close)  to 
City  Hall  so  that  City  employees  particularly  involved  with  this  contract  and 
located  at  City  Hall  can  only  to  a  very  marginal  extent,  easily  and  conveniently, 
from  a  time  and  distance  perspective,  inspect,  monitor,  quality  control,  access, 
communicate  and  conduct  face  to  face  meetings,  etc.  on  a  routine  and  ad  hoc  basis 
as  needed.  The  evaluation  will  be  based  on  an  overall  assessment  of  the  locations 
of  personnel  and  facilities.  However,  in  general,  to  qualify  for  a  Not  Advantageous 
rating,  the  Boston  Project  Manager  and  other  key  local  systems  personnel  shall  be 
located  within  approximately  2  (two)  and  5  (five)  miles  of  City  Hall;  and/or  the 
mail  sorting  operation,  the  Lockbox  and  the  Ticket  Data  Entry  facilities  shall  be 
located  within  approximately  5  (five)  and  10  (ten)  miles  of  City  Hall;  and/or  a 
Prime  Vendor  PVPMISS  administrative/management  office  shall  be  located  within 
approximately  5  (five)  and  10  (ten)  miles  of  City  Hall. 
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CRITERION  #3: 

OPERATION/MANAGEMENT  PLAN  AND  PLAN  OF  SERVICES  AND 
PERSONNEL  DEPTH,  QUALIFICATIONS,  EXPERIENCE 
AND  PERFORMANCE 

UNACCEPTABLE: 


The  Prime  Vendor  has  less  than  two  (2)  years  direct  experience  in  PVPMISS 
installations  similar,  comparable  and  analogous  to  Boston's,  and  less  than  one  (1) 
year  experience  within  the  time  period  July  1,  2006  through  July  1,  2009. 


The  proposer  has  detailed,  described  and  substantiated  its  ability  to  provide  only  a 
generally  deficient  single-point-of-contract  role  and  responsibility  where  the  Prime 
Vendor  will  be  directly  overseeing,  managing,  administering  and  quality 
controlling  the  complete  PVPMISS,  and  further,  will  be  directly  providing  the 
Prime  Vendor-preferably  developed,  primary  EDP  systems  and  subsystems  (e.g. 
database  management  system,  all  on-line  systems)  and  directly  providing  and 
performing  and/or  providing  via  secondary  vendors  other  services  and  functions 
(e.g.  data  entry,  microfilming,  lockbox  processing,  mail  house  processing)  in  a 
viable,  cohesive  and  effective  manner;  and/or,  in  further  regards  to  any 
requirements  performed  and  provided  via  secondary  vendors,  the  response  details, 
describes  and  substantiates,  for  only  a  deficient  single-point-of-contract 
responsibility,  the  relationship  between  the  Prime  Vendor  and  secondary  vendors 
and  any  and  all  approaches  and  steps  that  will  be  taken  to  oversee  and  quality 
control  the  work  product  and  other  duties  and  responsibilities  of  the  secondary 
vendor;  and/or,  the  Prime  Vendor  has  not  sufficiently  demonstrated  and  proven  its 
ability  to  provide  efficient  and  effective  similar  single-point-of-contract  roles  and 
responsibilities  to  its  other  PVPMISS  installations  which  are  similar  and 
comparable  to  Boston. 


The  proposal's  detail,  documentation,  substantiation  and  demonstration  of  specific 
Boston  Office  organization  is  generally  deficient  in  clarity  and  detail  so  as  to 
provide  a  negative  assessment  that  the  proposer's  contract  management  plan  and 
service  plan  is  effective,  efficient  and  viable  and  will  provide  the  proposer  with  the 
ability  to  efficiently  and  effectively  comply  with  the  Scope  of  Services  of  the  RFP; 
and/or,  the  proposer  has  been  generally  deficient  in  demonstrating  and  proving  its 
ability  to  provide  similar  organizational  resources  and  structures  that  comprise  a 
Local  PVPMISS  Office  to  its  other  PVPMISS  installations  which  are  similar  and 
comparable  to  Boston. 


The  proposal's  detail,  documentation,  substantiation  and  demonstration  of  specific  a 
specific  Data  Center/'Head  Office'  with  personnel  and  organization  is  generally 
deficient  in  clarity  and  detail  so  as  to  provide  a  negative  assessment  that  the 
proposer's  contract  management  plan  and  service  plan  is  effective,  efficient  and 
viable,  and  will  provide  the  proposer  with  the  ability  to  efficiently  and  effectively 
complete  the  Scope  of  Services  of  the  RFP,  and/or,  the  proposer  has  been  generally 
deficient  in  demonstrating  and  proving  its  ability  to  provide  similar  organizational 
resources  and  structures  that  comprise  a  Data  Center/'Head  Office'  to  its  other 
PVPMISS  installations  which  are  similar  and  comparable  to  Boston. 
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CRITERION  #3: 

OPERATION/MANAGEMENT  PLAN  AND  PLAN  OF  SERVICES  AND 
PERSONNEL  DEPTH,  QUALIFICATIONS,  EXPERIENCE 
AND  PERFORMANCE 

UNACCEPTABLE:  (cont.) 


5     The  authority  of  the  company  staff  directly  involved  in  the  proposed  Boston 
contract  (in  particular  the  Boston  Office,  Boston  PVPMISS  Project  Manager,  the 
Data  Center  Boston  PVPMISS  Project  Manager  and  key  management,  technical 
and  administrative  managers  directly  involved  with  the  Boston  PVPMISS  contract) 
and  these  persons'  position  in  the  company  /  corporate  hierarchy  in  addition  to  their 
reporting  relationships  with  the  higher  echelon  of  management,  is  determined  to 
provide  an  inadequate  level  of  assurance  that  the  project  team's  command  of 
company  /  corporate  resources  is  sufficient  so  as  to  complete  successfully  the  scope 
of  the  RFP  and  to  adequately  respond  to  problems  and  changing  conditions. 


6    The  proposer  has  identified  and  committed  an  inadequate  group  (in  terms  of 

numbers,  quality  and  diversity)  of  experienced  PVPMISS  Boston  located  and  non- 
Boston  located  Key  Personnel  that  would  be  required  to  provide,  operate  and 
enhance  Boston's  PVPMISS  with  adequate  effectiveness  and  efficiency. 


7    An  inadequate  number  of  Key  Personnel  are  proven  to  possess  an  adequate  level  of 
actual  and  direct  PVPMISS  experience  and  past  performance  in  PVPMISS 
operating  environments  similar  to  Boston's  in  terms  of  complexity,  volumes,  types 
of  transactions,  scope/range  of  systems  and  operations,  and  other  RFP  requirements 
or  most  Key  Personnel  are  proven  to  possess  an  inadequate  level  of  actual  and 
direct  PVPMISS  experience  and  past  performance  in  PVPMISS  operating 
environments  similar  to  Boston's  in  terms  of  complexity,  volumes,  types  of 
transactions,  scope/range  of  systems  and  operations  and  other  RFP  requirements. 


8     The  proposer  has  provided  an  inadequate  level  of  assurance  that  the  specifically 
committed  Key  Personnel  can  reasonably  be  expected  to  be  provided  in  terms  of 
the  proposer's  depth  of  PVPMISS  personnel  and  other  contractual  commitments  in 
other  municipalities. 


9     The  proposer  has  provided  an  inadequate  level  of  assurance  that  it  is  capable  of 
effectively  providing,  operating  and  enhancing  the  Boston  PVPMISS  with  other 
Key  Personnel  in  cases  of  staff  turnover  or  an  increase/  surge  in  projects  or  the 
introduction  of  problems  caused  by  changing  conditions. 


10  The  proposer  has  committed  an  inadequate  number  of  diverse  and  qualified  Boston 
based  and  non-Boston  based  Support  Personnel  that  would  be  required  to  provide 
and  operate  Boston's  PVPMISS  with  adequate  effectiveness  and  efficiency. 
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CRITERION  #3: 

OPERATION/MANAGEMENT  PLAN  AND  PLAN  OF  SERVICES  AND 
PERSONNEL  DEPTH,  QUALIFICATIONS,  EXPERIENCE 
AND  PERFORMANCE 

UNACCEPTABLE  (cont.): 


11  The  proposer's  project  organization  and  the  quality  and  depth  of  the  proposer's 
identified  Key  and  Support  PVPMISS  Personnel  provide  an  inadequate  level  of 
assurance  that  the  City's  relevant  operational  costs  would  be  minimized  or  reduced 
or  would  not  increase. 


12  The  proposer's  project  organization  and  the  quality  and  depth  of  the  proposer's 
identified  Key  and  Support  PVPMISS  Personnel  provide  an  inadequate  level  of 
assurance  that  the  City  would  have  the  ability  to  move  forward  on  July  1,  2010 
(and  throughout  the  full  term  of  the  proposed  contract)  with  the  development  and 
implementation  of  ongoing  enhancements  and  improvements  in  public 
responsiveness  and  customer  service,  continued  generation  of  operational 
efficiencies  and  increased  revenues. 


13  The  physical  location  of  critical  facilities  and  personnel,  not  including  the  main 
Data  Center,  are  generally  not  sited  for  the  most  part,  in  proximity  (close)  to  City 
Hall  so  that  City  employees  particularly  involved  with  this  contract  and  located  at 
City  Hall  cannot  easily  and  conveniently,  from  a  time  and  distance  perspective, 
inspect,  monitor,  quality  control,  access,  communicate  and  conduct  face  to  face 
meetings,  etc.  on  a  routine  and  ad  hoc  basis  as  needed.  The  evaluation  will  be 
based  on  an  overall  assessment  of  the  locations  of  personnel  and  facilities. 
However,  in  general,  to  qualify  for  an  Unacceptable  rating,  the  Boston  Project 
Manager  and  other  key  local  systems  personnel  shall  be  located  beyond 
approximately  5  (five)  miles  of  City  Hall;  and/or  the  mail  sorting  operation,  the 
Lockbox,  the  Ticket  Data  Entry  facilities  shall  be  located  beyond  approximately  10 
(ten)  miles  of  City  Hall;  and/or  a  Prime  Vendor  PVPMISS 
administrative/management  office  shall  be  located  beyond  approximately  10  (ten) 
miles  of  City  Hall. 
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(7.4)  COMPARATIVE  CRITERION  #  4: 


RMV  INTERFACE  EXPERIENCE,  KNOWLEDGE,  CAPABILITY  AND 
DEMONSTRATED  EFFICIENT  AND  EFFECTIVE  PERFORMANCE 
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CRITERION  #  4: 

RMV  INTERFACE  EXPERIENCE,  KNOWLEDGE,  CAPABILITY  AND 
DEMONSTRATED  EFFICIENT  AND  EFFECTIVE  PERFORMANCE 

HIGHLY  ADVANTAGEOUS: 


1  The  proposer  comprehensively  and  clearly  documents,  substantiates  and 
demonstrates  extensive  previous  and  current  direct  experience,  knowledge  and 
capabilities  and  excellent  performance  and  effectiveness  with  the  City's  RMV 
interface  requirements  based  upon  their  provision  and  operation  in  PVPMISS 
installations  similar  and  comparable  to  Boston  (in  terms  such  as  size,  volumes,  use 
and  manipulation  of  RMV  data,  sophistication,  number/types/frequency  of 
transactions,  edits  and  quality  controls)  and  provides  the  highest  level  of  assurance 
that  the  proposer  can  minimize  disruption  or  risk  to  the  City's  current  level  and 
quality  of  enforcement  and  customer  service/public  responsiveness  components  and 
efforts  and  collection  rates. 


2  The  proposer  comprehensively  and  clearly  documents,  substantiates  and 

demonstrates  extensive  PVPMISS  interface  experience,  knowledge  and  capabilities 
and  excellent  PVPMISS  interface  performance  and  effectiveness  with  the 
Massachusetts  RMV  and  provides  the  highest  degree  of  assurance  that  disruption  or 
risk  to  the  City's  current  level  and  quality  of  Massachusetts  RMV  interface  services 
(in  terms  such  as  on-line  access,  registrant  identification,  non-renewal  mark  and 
clear,  and  adaptation  to  RMV  changes)  can  be  prevented  or  extremely  minimized 
throughout  the  full  term  of  the  proposed  contract  period. 


3  The  proposer  comprehensively  and  clearly  documents,  substantiates  and 

demonstrates  extensive  PVPMISS  interface  experience,  knowledge  and  capabilities 
and  excellent  PVPMISS  interface  performance  and  effectiveness  with  numerous 
Non-Massachusetts  RMVs  and  provides  the  highest  degree  of  assurance  that 
disruption  or  risk  to  the  City's  current  level  and  quality  of  Non-Massachusetts  RMV 
interface  services  (in  terms  such  as  registrant  identification  and  adaptation  to  RMV 
changes)  can  be  prevented  or  extremely  minimized  throughout  the  full  term  of  the 
proposed  contract  period. 


4  The  credibility  of  the  proposer's  RFP  responses  in  terms  of  demonstrated  capability 
to  comply  with  specified  requirements  throughout  the  full  term  of  the  proposed 
contract  is  determined  to  be  optimal. 
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CRITERION  #  4: 

RMV  INTERFACE  EXPERIENCE,  KNOWLEDGE,  CAPABILITY  AND 
DEMONSTRATED  EFFICIENT  AND  EFFECTIVE  PERFORMANCE 

ADVANTAGEOUS: 


1  The  proposer  comprehensively  and  clearly  documents,  substantiates  and 
demonstrates  extensive  previous  and  current  direct  experience,  knowledge  and 
capabilities  and  good  performance  and  effectiveness  with  the  City's  RMV  interface 
requirements  based  upon  their  provision  and  operation  in  PVPMISS  installations 
similar  and  comparable  to  Boston  (in  terms  such  as  size,  volumes,  use  and 
manipulation  of  RMV  data,  sophistication,  number/types/frequency  of  transactions, 
edits  and  quality  controls)  and  provides  a  high  level  of  assurance  that  the  proposer 
can  minimize  disruption  or  risk  to  the  City's  current  level  and  quality  of  enforcement 
and  customer  service/public  responsiveness  components  and  efforts  and  collection 
rates. 


2  The  proposer  comprehensively  and  clearly  documents,  substantiates  and 

demonstrates  extensive  PVPMISS  interface  experience,  knowledge  and  capabilities 
and  good  PVPMISS  interface  performance  and  effectiveness  with  the  Massachusetts 
RMV  and  provides  a  high  degree  of  assurance  that  disruption  or  risk  to  the  City's 
current  level  and  quality  of  Massachusetts  RMV  interface  services  (in  terms  such  as 
on-line  access,  registrant  identification,  non-renewal  mark  and  clear,  and  adaptation 
to  RMV  changes)  can  be  prevented  or  extremely  minimized  throughout  the  full  term 
of  the  proposed  contract  period. 


3  The  proposer  comprehensively  and  clearly  documents,  substantiates  and 

demonstrates  extensive  PVPMISS  interface  experience,  knowledge  and  capabilities 
and  good  PVPMISS  interface  performance  and  effectiveness  with  numerous  Non- 
Massachusetts  RMVs  and  provides  a  high  degree  of  assurance  that  disruption  or  risk 
to  the  City's  current  level  and  quality  of  Non-  Massachusetts  RMV  interface  services 
(in  terms  such  as  registrant  identification  and  adaptation  to  RMV  changes)  can  be 
prevented  or  extremely  minimized  throughout  the  full  term  of  the  proposed  contract 
period. 


4  The  credibility  of  the  proposer's  RFP  responses  in  terms  of  demonstrated  capability 
to  comply  with  specified  requirements  throughout  the  full  term  of  the  proposed 
contract  is  determined  to  be  good. 
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CRITERION  #  4: 

RMV  INTERFACE  EXPERIENCE,  KNOWLEDGE,  CAPABILITY  AND 
DEMONSTRATED  EFFICIENT  AND  EFFECTIVE  PERFORMANCE 

NOT  ADVANTAGEOUS: 


1  The  proposer's  detail,  documentation,  substantiation  and  demonstration  of  previous 
and  current  direct  experience,  knowledge,  capabilities  and  performance  with  the 
City's  RMVs  interface  requirements  based  upon  their  provision  and  operation  in 
PVPMISS  installations  similar  and  comparable  to  Boston  (in  such  terms  as  size, 
volumes,  use  and  manipulation  of  RMV  data,  sophistication, 
number/types/frequency  of  transactions,  edits  and  quality  controls)  is  sufficiently 
unclear  or  lacks  details  required  to  adequately  assess  the  relative  value  of  the 
proposer's  experience  or  performance  above  a  marginal  level; 

AND/OR 

The  depth  and/or  duration  of  similar  and  comparable  to  Boston  experience  (in  terms 
such  as  size,  volumes,  etc.)  —  or  the  quality  of  performance  and  effectiveness  with 
the  City's  RMV  interface  requirements  —  is  only  marginal  or  is  determined  to  pose 
undue  risk  or  potential  for  disruption  to  the  City's  current  level  and  quality  of 
enforcement  and  customer  service/public  responsiveness  components  and  efforts  or 
collection  rates. 


2  The  proposer's  detail,  documentation,  substantiation  and  demonstration  of  previous 
and  current  direct  interface  experience,  knowledge,  capabilities  and  performance 
with  the  Massachusetts  RMV  is  sufficiently  unclear  or  lacks  details  required  to 
adequately  assess  the  relative  value  of  the  proposer's  experience  or  performance 
above  a  marginal  level; 

AND/OR 

The  depth  and/or  duration  of  Massachusetts  RMV  interface  experience  —  or  the 
quality  of  performance  and  effectiveness  of  Massachusetts  RMV  interface 
experience  —  is  only  marginal  or  is  determined  to  pose  undue  risk  or  potential  for 
disruption  to  the  City's  current  level  and  quality  of  Massachusetts  RMV  interface 
services  (in  terms  such  as  on-line  access,  registrant  identification,  non-renewal  mark 
and  clear,  and  adaptation  to  RMV  changes). 
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CRITERION  #  4: 

RMV  INTERFACE  EXPERIENCE,  KNOWLEDGE,  CAPABILITY  AND 
DEMONSTRATED  EFFICIENT  AND  EFFECTIVE  PERFORMANCE 

NOT  ADVANTAGEOUS:  (continued) 


3  The  proposer's  detail,  documentation,  substantiation  and  demonstration  of  previous 
and  current  direct  interface  experience,  knowledge,  capabilities  and  performance 
with  Non-Massachusetts  RMVs  is  sufficiently  unclear  or  lacks  details  required  to 
adequately  assess  the  relative  value  of  the  proposer's  experience  or  performance 
above  a  marginal  level; 

AND/OR 

The  depth  and/or  duration  of  Non-Massachusetts  RMVs  interface  experience  (in 
particular,  with  the  following  RMVs  in  order  of  priority:  New  Hampshire,  New 
York,  Connecticut,  Rhode  Island,  New  Jersey,  Maine,  Pennsylvania,  Florida  and 
California)  —  or  the  quality  of  performance  and  effectiveness  of  Non-Massachusetts 
RMVs  interface  experience  —  is  only  marginal  or  is  determined  to  pose  undue  risk  or 
potential  for  disruption  to  the  City's  current  level  and  quality  of  Non-Massachusetts 
RMV  interface  services  (in  terms  such  as  registrant  identification  and  adaptation  to 
RMV  changes). 


4  The  credibility  of  the  proposer's  RFP  responses  in  terms  of  demonstrated  capability 
to  comply  with  specified  requirements  throughout  the  full  term  of  the  proposed 
contract  is  determined  to  be  only  marginal. 
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CRITERION  #  4: 

RMV  INTERFACE  EXPERIENCE,  KNOWLEDGE,  CAPABILITY  AND 
DEMONSTRATED  EFFICIENT  AND  EFFECTIVE  PERFORMANCE 

UNACCEPTABLE: 


1  The  proposer's  detail,  documentation,  substantiation  and  demonstration  of  previous 
and  current  direct  experience,  knowledge,  capabilities,  performance  or  effectiveness 
with  the  City's  RMV  interface  requirements  based  upon  their  provision  and  operation 
in  PVPMISS  installations  similar  and  comparable  to  Boston  (in  such  terms  as  size, 
volumes,  use  and  manipulation  of  data,  sophistication,  number/types/frequency  of 
transactions,  edits  and  quality  controls)  is  deficient  so  as  to  provide  a  negative 
assessment  of  the  relative  value  of  the  proposer's  experience,  capability, 
qualifications  or  performance; 

AND/OR 

The  level  of  similar  and  comparable  to  Boston  experience  (in  terms  such  as  size, 
volumes,  etc.)  -  or  the  quality  of  performance  and  effectiveness  with  the  City's 
RMVs  interface  requirements  —  is  determined  to  be  deficient  or  to  provide 
substantial  risk  or  potential  for  disruption  to  the  City's  current  level  and  quality  of 
enforcement  and  customer  service/public  responsiveness  components  and  efforts  or 
collection  rates. 


2  The  proposer's  detail,  documentation,  substantiation  and  demonstration  of  previous 
and  current  direct  interface  experience,  knowledge,  capabilities,  performance  or 
effectiveness  with  the  Massachusetts  RMV  is  deficient  so  as  to  provide  a  negative 
assessment  of  the  relative  value  of  the  proposer's  experience,  capability, 
qualifications  or  performance; 

AND/OR 

The  level  of  Massachusetts  RMV  interface  experience  —  or  the  quality  of 
performance  and  effectiveness  of  Massachusetts  RMV  interface  experience  —  is 
determined  to  be  deficient  or  to  provide  substantial  risk  or  potential  for  disruption  to 
the  City's  current  level  and  quality  of  Massachusetts  RMV  interface  services  (in 
terms  such  as  on-line  access,  registrant  identification,  non-renewal  mark  and  clear, 
and  adaptation  to  RMV  changes). 
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CRITERION  #  4: 

RMV  INTERFACE  EXPERIENCE,  KNOWLEDGE,  CAPABILITY  AND 
DEMONSTRATED  EFFICIENT  AND  EFFECTIVE  PERFORMANCE 

UNACCEPTABLE:  (continued) 


3  The  proposer's  detail,  documentation,  substantiation  and  demonstration  of  previous 
and  current  direct  interface  experience,  knowledge,  capabilities,  performance  or 
effectiveness  with  Non-Massachusetts  RMVs  is  deficient  so  as  to  provide  a  negative 
assessment  of  the  relative  value  of  the  proposer's  experience,  capability, 
qualifications  or  performance; 

AND/OR 

The  level  of  Non-Massachusetts  RMVs  interface  experience  (in  particular,  with  the 
following  RMVs  in  order  of  priority:  New  Hampshire,  New  York,  Connecticut, 
Rhode  Island,  New  Jersey,  Maine,  Pennsylvania,  Florida  and  California)  —  or  the 
quality  of  performance  and  effectiveness  of  Non-Massachusetts  RMVs  interface 
experience  —  is  determined  to  be  deficient  or  to  provide  substantial  risk  or  potential 
for  disruption  to  the  City's  current  level  and  quality  of  Non-Massachusetts  RMV 
interface  services  (in  terms  such  as  registrant  identification  and  adaptation  to  RMV 
changes). 


4  The  credibility  of  the  proposer's  RFP  responses  in  terms  of  demonstrated  capability 
to  comply  with  specified  requirements  throughout  the  full  term  of  the  proposed 
contract  is  determined  to  be  deficient. 
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SECTION  8.0 
INSTRUCTIONS  FOR  THE  COMPOSITION  OF  THE 


TECHNICAL  (NON-PRICE)  PROPOSAL  AND  INFORMATION 
RELATING  TO  THE  EVALUATION  THEREOF 


(8.1)  Sources  of  Information  for  Evaluating  Proposals  in  Accordance 
With  the  Comparative  Criteria 

To  obtain  the  understanding  required  to  evaluate  a  proposal  and  to  recommend  proposal 
selection  and  contract  award,  the  City  shall  obtain  information  and  knowledge  about  the 
ability  of  a  proposer  to  provide  and  operate  the  PVPMISS  and  perform  all  related  services 
in  a  manner  that  will  be  more  advantageous  to  the  City  than  that  of  any  other  proposers. 
The  City  shall  gather  this  knowledge  from  the  sources  described  below.  The  anticipated 
time  frame  within  which  the  City  shall  gather  this  information  and  within  which  proposers 
shall  accommodate  the  City  is  set  forth  in  section  3.0  of  this  RFP,  paragraph  3.13, 
'Tentative  Schedule  of  Events'  ('Evaluation  of  Proposals').  The  City  reserves  the  right  to 
extend  or  modify  said  time  frame. 

It  is  very  important  to  note  that  the  written  proposal,  largely  consisting  of  items  'a',  'b',  and 
'c',  below,  may  be  the  primary  source  of  information  and  knowledge  utilized  by  the 
Evaluation  Committee. 


The  above  mentioned  sources  of  information  and  knowledge  for  the  evaluation  of  proposals 
are: 


a)    RESPONSE  TO  THE  SCOPE  OF  SERVICES:  Constitutes  the  proposers'  responses 
to  the  substantial  detail,  requirements  and  objectives  of  the  City  set  forth  in  the 
Scope  of  Services  section  of  the  RFP.  It  is  of  the  utmost  importance  for  proposers 
to  be  as  detailed,  comprehensive  and  clear  as  possible  in  their  responses  to  the 
Scope  of  Services. 


b)    RESPONSE  FORMS  AND  QUESTIONNAIRES:  Constitutes  the  proposers' 
provision  of  and  responses  to  the  various  forms,  resumes,  and  questionnaires 
required  by  the  City.  It  is  of  the  utmost  importance  for  proposers  to  be  as  detailed, 
comprehensive  and  clear  as  possible  in  their  responses  to  the  forms  and 
questionnaires. 
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DOCUMENTATION:  Constitutes  the  proposers'  description  and  provision  of 
actual  documentation  relative  to  each  RFP  system  or  service  (with  the  emphasis  on 
systems)  such  as:  user  guides/manuals  for  on-line  systems  viewing,  on-line  systems 
processing,  MIS  and  other  reports,  etc.;  user-oriented  system  processing 
explanations;  user-oriented  criteria  and  condition  statements  for  system  activities, 
events  and  functions;  user-oriented  functional  specifications  and  descriptions  of 
software  programs  and  relationships  between  different  programs;  user-  oriented 
descriptions  of  operational  service  functions;  etc.  These  sources  of  information  are 
essential  relative  to  the  City's  ability  to  obtain  critical  information  concerning  a 
proposer's  capabilities.  This  documentation  is  crucial  in  and  of  itself  as  the  success 
of  any  entire  system  relies  on  the  formal  descriptions  of  how,  what,  when,  where, 
and  why  components  in  the  system  work.  Furthermore,  this  documentation  will 
help  support  and  demonstrate  similarity  and  comparability,  assess  flexibility  and 
functionality,  and  assess  the  amount  and  scope  of  revisions  and/or  new  efforts  that 
will  be  required  to  have  the  PVPMISS  operational  July  1,  2010  in  Boston.  It 
therefore  benefits  proposers  to  provide  detailed,  reader-friendly  and  comprehensive 
documentation. 


REFERENCES  AND  EXPERIENCE  VERIFICATION:  The  Evaluation 
Committee  may  /  shall  likely  contact  by  telephone  and/or  writing  (and  reserves  the 
right  to  visit)  PVPMISS  customer  references  to  help  determine  and  verify  the 
quality,  timeliness,  accuracy,  overall  responsiveness,  depth,  and  relevance  of 
previous  and/or  current  work.  This  investigation  shall  also  focus  on  the  degree  to 
which  proposers'  written  proposals  conform  to  the  information  gathered  by 
references.  The  credibility  of  a  proposal  can  be  called  into  question  if  reference 
investigations  reveal  a  situation  that  is  not  accurately  depicted  in  the  written 
proposal. 


DEMONSTRATIONS  and  ORAL  PRESENTATIONS:  Depending  upon 
circumstances,  and  solely  at  its  discretion,  the  City  reserves  the  right  to  require 
proposers  to  perform,  at  Boston  City  Hall,  in-depth  demonstrations  of  the  proposed 
on-line  PVPMISS  computer  system,  in  addition  to  oral  presentations  concerning 
those  elements  of  the  Scope  of  Services  relating  to  services  and  'transparent'  data 
processing  issues,  such  as  edits  and  controls,  system  flexibility,  etc.  The  credibility 
of  a  proposal  can  be  called  into  question  if  system  demonstrations  or  oral 
presentations  reveal  a  situation  that  is  not  accurately  depicted  in  the  written 
proposal.  Proposers  are  cautioned  that  the  City  is  not  required  to  hold 
demonstrations  or  oral  presentations.  It  therefore  benefits  a  proposer  to  be  as 
detailed,  comprehensive  and  clear  as  possible  in  its  response  to  the  Scope  of 
Services  and  the  response  forms  and  questionnaires  and  to  provide  adequate 
documentation. 
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SITE  VISITS:  Depending  upon  circumstances,  and  solely  at  its  discretion,  the  City 
reserves  the  right  to  conduct  a  minimum  of  one  (1)  comprehensive  site  visit  to  an 
actual  PVPMISS  installation(s)  designated  by  a  proposer  to  be  most  similar  and 
comparable  to  Boston's  PVPMISS  system  and  service  requirements  in  terms  such  as 
size,  types  and  volumes  of  transactions,  sophistication,  etc.  The  credibility  of  a 
proposal  can  be  called  into  question  in  the  event  a  site  visit  reveals  a  situation  that  is 
not  accurately  depicted  in  the  written  proposal.  Proposers  are  cautioned  that  the 
City  is  not  required  to  conduct  a  site  visit.  It  therefore  benefits  a  proposer  to  be  as 
detailed,  comprehensive  and  clear  as  possible  in  its  response  to  the  Scope  of 
Services  and  the  response  forms  and  questionnaires  and  to  provide  adequate 
documentation. 


CLARIFICATION  OF  PROPOSALS:  Any  proposer  may  be  required  to  clarify  (in 
writing)  its  proposal  with  the  Evaluation  Committee  at  any  time  during  the 
procurement  process.  Proposers  are  cautioned  that  the  Evaluation  Committee  is  not 
required  to  seek  clarification  of  proposer's  proposals.  It  therefore  benefits  a 
Proposer  to  be  as  detailed,  comprehensive,  clear  and  unambiguous  as  possible  in  its 
response  to  the  Scope  of  Services  and  response  forms  and  questionnaires  and  to 
provide  adequate  documentation. 


INFORMATION  NOT  SUPPLIED  BY  PROPOSERS:  Please  be  aware  that  the 
City  may  use,  solely  at  its  discretion,  sources  of  information  not  supplied  by  the 
proposer  concerning  the  proposer's  ability  to  perform  the  work  specified  in  this 
RFP.  Such  sources  may  include  current  or  past  customers  of  the  organization; 
current  or  past  suppliers;  articles  from  data  processing,  governmental  and  related 
publications;  articles  from  other  published  sources  such  as  industry  newsletters  or 
from  nonpublished  sources  made  available  to  the  City.  Depending  upon 
circumstances,  the  City's  decision  to  use,  or  not  to  use,  such  sources  of  information 
concerning  the  ability  to  perform  the  work  specified  in  this  RFP  may  be  contingent 
upon  the  reasonable  verification  of  such  information  and/or  answers  received  in 
response  to  written  questions  submitted  to  the  proposer  by  the  City  regarding  such 
information. 
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(8.2)  Overview  of  Instructions  to  Proposers  to  be  Adhered  to  in  the  Composition  and 
Provision  of  the  Technical  Written  Proposal 

To  allow  for  the  comparative  analysis  and  evaluation  of  proposals,  it  is  required  that  a 
uniform  format  be  employed  in  structuring  each  proposal.  The  proposer's  degree  of 
compliance  with  the  requirements  of  this  RFP  will  be  a  factor  in  the  subsequent  evaluation 
of  its  proposal.  The  City  reserves  the  right  to  not  consider  for  detailed  study  proposals  with 
substantive  deviations  or  omissions. 

The  written  proposal  shall  consist  primarily  of  a  response  to  the  following  as  well  as  the 
provision  of  required  documentation: 


a)    each  Scope  of  Services  section  and  each  item,  requirement  and  specification  within 
each  section, 


b)    each  response  form  and  questionnaire  and  each  item  within  each  form  and 
questionnaire, 


Proposer's  responses  to  'a'  and  'b'  above  should  be  presented  in  a  detailed,  comprehensive, 
clear  and  concise  manner  so  that  all  features,  attributes  and  benefits  of  the  proposer's 
experience,  knowledge,  expertise,  systems  and  services  can  be  fully  ascertained. 
Proposers  are  advised  that  each  response  should  fully  satisfy  the  relevant  item, 
requirement  or  specification.  Proposers  should  not  expect  the  City  to  draw  inferences 
from  vague  proposal  responses,  to  routinely  cross  reference  other  sections  of 
proposals,  or  to  simply  accept  at  'face  value'  marketing  oriented  statements 
purporting  advantageous  systems  or  services  without  providing  justification  and 
support  for  said  claims. 

The  City  desires  to  obtain  a  high  quality,  extremely  unified  and  integrated  PVPMISS  that 
has  the  functionality,  utility  and  flexibility  to  meet  the  high  standards  of  the  City.  The  City 
also  expects  this  PVPMISS  to  be  highly  cost  effective  and  cost  justifiable  and  to  enhance 
the  City's  parking  management  related  activities. 
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(8.3)  Detailed  Instructions  to  Proposers  to  be  Adhered  to  in  the  Composition  and 
Provision  of  the  Technical  Written  Proposal: 

Response  to  the  Scope  of  Services  and  Provision  of  Documentation 

The  City  needs  to  know  a  great  deal  of  information  about  the  PVPMISS  being  proposed. 
Therefore,  in  specific  regards  to  the  information,  requirements  and  specifications 
comprising  the  Scope  of  Services  section  of  this  RFP  (Section  4.0),  the  proposer's  responses 
should  include  but  not  be  limited  to: 


1)    For  each  section  of  the  Scope  of  Services,  a  summary,  inclusive  and  effective-date 
specific  statement(s)  of  complete  compliance  with  the  specifications  and 
requirements  therein  that  cover  each  and  every  item,  task,  deliverable,  etc.  If 
compliance  is  in  any  way  conditional  or  exceptions  are  taken  to  any  items,  etc., 
within  a  specific  Scope  of  Services  section,  then  those  conditional  or  exception 
items,  etc.,  shall  be  clearly  cited  in  a  separate  summary  statement(s)  which  shall 
specifically  reference  the  title  and  numbered  paragraph  (from  the  Scope  of  Services) 
of  the  item,  etc.  The  summary  statement(s)  shall  also  include  a  brief/summary 
reason,  alternate  effective  date,  etc.  A  detailed  and  thorough  discussion  of  the 
conditional  or  exception  item,  etc.,  along  with  any  and  all  reasons  and  alternate 
delivery  dates,  approaches,  etc.,  is  required  in  a  separate  section  of  any  submitted 
proposal.  Said  section  shall  be  clearly  titled  "Exceptions  or  Conditional 
Compliance  with  the  RFP". 

The  summary  statement(s)  referred  to  above  shall  include  the  page  and  paragraph 
number  (or  alternate  indexing  method)  within  the  "Exceptions  or  Conditional 
Compliance  with  the  RFP"  section  of  the  proposal  where  the  detailed  and  thorough 
discussion  of  the  conditional  or  exception  item,  etc.,  can  be  found.  Proposers 
should  refer  to  the  paragraph  titled  "Exceptions  to  the  RFP"  which  is  set  forth  in 
section  '8.5.8'  of  the  RFP. 

Proposers  are  reminded  that  if  a  statement(s)  of  conditional  compliance  or  exception 
is  provided,  a  separate  statement(s)  of  compliance  covering  all  non-conditional  or 
non-exception  items  is  required. 


2)  A  detailed,  thorough,  comprehensive,  specific  and  clear  written  description  and 
discussion  of,  and  reply  to,  each  system  element,  feature,  service,  etc..  required 
under  the  Scope  of  Services. 

Said  written  description  and  discussion  of,  and  reply  to,  each  system  element,  etc., 
shall  specifically  reference  the  title  and  numbered  paragraph  (from  the  Scope  of 
Services)  of  the  item,  etc.,  being  responded  to. 
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Said  written  description  and  discussion  shall  include,  but  is  not  limited  to:  the  scope 
and  particular  features  and  benefits  related  to  the  proposer's  provision  of  each 
element,  feature,  service,  etc.;  detailed  information  relative  to  criteria  and  conditions 
associated  with  the  processing  and  activities  of  the  PVPMISS;  detailed  descriptions 
of  functionality  and  utility;  etc.;  vis-a-vis  the  City's  needs  as  defined  in  the  Scope  of 
Services. 


In  addition,  and  of  particular  importance  to  the  City,  said  written  description  and 
discussion  shall  include  the  provision  of  pictorial  presentations  of  actual  on-line  and 
other  output  relevant  to  the  item,  etc.,  under  discussion.  Said  output  and  product 
samples  should  be  included  for  as  many  items  as  possible.  Otherwise,  the  City  will 
be  unable  to  adequately  evaluate  a  particular  item,  etc.,  and  shall  be  obligated  to 
assume  that  said  item,  etc.,  does  not  exist  or  cannot  be  delivered  as  required.  From 
a  format  perspective,  the  City  desires  that  said  output  and  product  samples  be 
integrated  with  the  text  of  the  proposal.  At  a  minimum,  such  pictorials  shall  be 
included  on  separate  pages  within  the  relevant  section  of  the  Scope  of  Services 
being  responded  to.  If  such  pictorials  do  not  represent  actual  data  or  originate  from 
a  test  or  demonstration  system,  the  proposer  shall  so  note  this  along  with  the 
provision  of  that/those  particular  pictorials. 


3)  As  part  of  the  written  description  and  discussion  of  each  numbered  paragraph  for  a 

system  element,  feature,  service,  etc.,  within  the  Scope  of  Services,  a  proposer  shall 
include  information  on  its  provision  and  operation  of  proven  and  established 
PVPMISS'  similar  and  analogous  to  the  PVPMISS  required  by  the  City  of  Boston 
with  similar  and  comparable  system  elements,  features,  services,  etc. 


In  presenting  such  information,  a  proposer  should  reference  and  provide  information 
for  up  to  three  (3)  PVPMISS  installations.  For  each  similar  and  comparable 
PVPMISS  system  element,  feature,  service,  etc.,  the  proposer  should  provide 
information  that  will  confirm  the  similarity  and  comparability  —  such  as  the  identity 
of  the  location/client  (e.g.,  name  of  the  city);  the  number  of  parking  tickets  issued 
annually;  the  number  and  types  of  transactions  typical  for  a  year;  the  length  of  time 
the  element,  feature,  service,  etc.,  has  been  provided,  and;  an  adequate  explanation 
and  clarification  relative  to  the  similarity  and  comparability  to  the  City  of  Boston's 
needs  and  requirements.  Proposers  may  state  and  present  alternative  experiences  to 
actual  PVPMISS  experience  relative  to  services  and  systems  which  they  believe 
offers  equivalent  experience  by  some  other  means,  and  the  City  at  its  sole  discretion 
will  review  and  consider  whether  the  proposed  alternative  achieves  equivalent 
experience  and  performance. 
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4)       A  detailed,  thorough,  comprehensive  specific  and  clear  description  and  discussion 
of  the  work  to  be  performed  on  the  proposer's  PVPMISS  for  each  item,  task, 
deliverable,  etc.,  so  that  the  effective  date  requirement  can  be  met  with  all  required 
functionality,  requirements,  and  benefits,  and  the  resources  that  are  required  and 
will  be  provided  for  each  item,  task,  deliverable,  etc.  Said  description  and 
discussion  should  demonstrate  the  proposer's  understanding  of  the  project, 
knowledge,  technical  skills,  and  ability  to  develop,  customize,  implement,  manage 
and  operate  services  and  systems  to  meet  the  City's  objectives  as  stated  in  this  RFP. 


5)       A  thorough  and  comprehensive  statement  regarding  the  proposer's  assessment  of  the 
difficulties,  major  or  otherwise  (if  any),  anticipated  in  properly  completing  the 
systems  and  services  required.  The  statement  should  also  clearly  indicate  what 
exact  aspects,  parts,  features,  benefits,  etc.,  relating  to  specific  systems  and  services 
will/may  not  be  provided  immediately  on  July  1,  2010.  (In  regards  to  conversion, 
the  statement  should  clearly  indicate  information  that  can  or  can  not  be  converted  or 
when  converted  cannot  be  immediately  utilized  as  intended.) 


6)       For  each  PVPMISS  system  or  subsystem,  in  addition  to  those  'transparent'  system 
components  that  serve  to  integrate  and  allow  for  'communication'  or  sharing  of  data 
between  various  systems,  a  detailed  and  comprehensive  description  of  available 
documentation.  (As  previously  defined,  documentation  constitutes:  user 
guides/manuals  for  on-line  systems  viewing,  on-line  systems  processing,  MIS  and 
other  reports,  etc.;  user-oriented  system  processing  explanations;  user-oriented 
criteria  and  condition  statements  for  system  activities,  events  and  functions;  user- 
oriented  functional  specifications  and  descriptions  of  software  programs  and 
relationships  between  different  programs;  user-oriented  descriptions  of  operational 
service  functions;  etc.)  Said  description  of  documentation  shall  also  provide  an 
index  as  to  where  (what  pages  of  what  document,  etc.)  in  the  proposers' 
documentation  a  particular  system  or  subsystem  is  described.  Alternatively, 
Proposers  can  integrate  the  documentation  into  their  Scope  of  Services  response, 
etc.  The  objective  is  to  provide,  at  a  minimum,  a  convenient  method  of  indexing  the 
material. 


Furthermore,  proposers  shall  provide  the  actual  documentation  for  systems  and 
subsystems.  In  the  event  that  certain  of  this  documentation  represents  trade  secrets 
or  proprietary  information,  the  Proposers  shall  make  said  material  available  to  the 
City  at  a  location  to  be  determined  by  a  Proposer,  so  long  as  said  location  is  situated 
within  approximately  a  one  (1)  mile  radius  from  Boston  City  Hall.  Proposers  shall 
allow  evaluators  unrestricted  access,  for  the  purposes  of  review  and  'note-taking',  to 
said  documentation  during  the  hours  of  9:00  a.m.  and  5:00  p.m.,  from  Monday 
through  Friday  (excluding  holidays),  during  the  evaluation  phase  of  this  RFP.  The 
before  mentioned  access  for  any  single  review  visit  shall  be  arranged  a  minimum  of 
twenty-four  (24)  hours  prior  to  said  visit. 
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(8.4)    Detailed  Instructions  to  Proposers  to  be  Adhered  to  in  the  Composition  and 

Provision  of  the  Technical  Written  Proposal:  Response  to  Response  Forms  and 
Questionnaires 


In  specific  regards  to  the  completion  of  response  forms  and  questionnaires,  the  City 
requires  information,  narratives,  organizational  charts,  etc.,  specific  to  that  form  or 
questionnaire,  such  as: 


•  information  on  direct  experience  in  the  successful  design  and  implementation  of 
similar  and  comparable  PVPMISS'; 

<- 

•  information  on  direct  experience  in  the  successful  provision  and  operation  of  similar 
and  comparable  PVPMISS'; 

<- 

•  past  performance  with  regard  to  meeting  cost,  schedule,  and  technical  proposal 
requirements  with  similar  and  comparable  PVPMISS'; 

<- 

•  employee  PVPMISS  experience  and  expertise  and  resumes; 
<- 

•  Plan  of  Service/Management  Plan 
<- 

•  etc. 

Where  not  self-explanatory,  instructions  to  proposers  regarding  the  provision  of  such 
information  are  provided  with  the  form  or  questionnaire.  As  a  general  guideline,  the 
proposers'  provision  of  said  information  shall  be  detailed,  comprehensive  and  clear. 

A  listing  of  the  response  forms  and  questionnaires  is  set  forth  on  the  following  page. 
Copies  of  the  actual  forms/questionnaires  appear  beginning  on  page  525  of  this  RFP. 

Please  note  that  forms  number  1  through  3  as  they  appear  in  this  RFP  have  been  reduced, 
for  packaging  purposes,  from  their  actual  size  of  8.5"  x  14"  to  8.5"  x  11".  "Full-  size" 
copies  of  these  forms,  and  additional  copies  of  all  other  forms,  shall  be  made  available  at 
the  Proposers'  Conference  or  at  any  other  time  at  the  request  of  a  proposer.  Also,  proposers 
may  reproduce  or  use  a  facsimile  of  the  forms  and  questionnaires.  However,  forms  number 
1  through  3  may  be  difficult  to  reproduce,  i.e.,  copy,  due  to  copy-enlargement 
considerations. 
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Listing  of  Response  Forms:  The  Forms  listed  below  appear  beginning  on  page  518  of  this 
RFP  document. 

FORM  A:       Minimum  Evaluation  Criteria  Response  Form 

Form  #1:        5  Large  Scale,  Full  Service  Clients  For  Primary  Parking  Ticket  Processing 
That  Are  Most  Similar  And  Comparable  To  Boston:  Summary  Data 

Form  #2:        Additional  10  PVPMISS  Clients  For  Primary  Ticket  Processing 

Form  #3:        5  Large  Scale,  Full  Service  Clients  For  Primary  Parking  Ticket  Processing 
That  Are  Most  Similar  And  Comparable  To  Boston:  Scope  of  Services 
Overview 


Form  #4: 

Proposer  PVPMISS  Experience  Form 

Form  #5: 

PVPMISS  Employee  Background  Form 

Form  #6: 

Motor  Vehicle  Agency  Interface  Experience  Form 

Form  #7: 

PVPMISS  Proposer  Overview  Form 

Form  #8: 

PVPMISS  Personnel  Matrix  Form 

Form  #9: 

Data  Center  Hardware  and  Technical  Environment  Form 

(8.5)  IMPORTANT  NOTES: 


(8.5.0)  Comparative  Evaluation  Criteria 

Proposers  should  thoroughly  familiarize  themselves  with  the  Comparative  Evaluation 
Criteria. 


(8.5.1)  Performance  Orientation 

This  RFP  is  oriented  and  places  a  heavy  emphasis  on  proven  and  demonstrated 
performance  and  effectiveness  and  optimal  functionality  and  utility  within  a  unified  and 
integrated  PVPMISS. 
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(8.5.2)  Incomplete  Discussion  of  Scope  of  Service  Requirements  or 
Failure  to  Furnish  Required  Information 

Proposers  are  informed  that  responses  to  Scope  of  Service  requirements  that  do  not  address 
all  items,  features  or  requirements,  or  the  failure  to  furnish  required  information  as  part  of 
the  proposal  will  be  considered  by  the  City  of  Boston  as  a  negative  answer  or  that  the 
proposer  cannot  meet  in  part  or  in  whole  the  specified  quantity,  quality,  type,  or  manner  of 
article,  component,  equipment  or  service  as  is  requested  in  this  Request  for  Proposal. 


(8.5.3)  Repeating  of  RFP  Wording 

It  should  be  noted  that  proposers  will  not  receive  credit  for  simply  repeating  RFP  wording. 
The  evaluation  of  proposals  requires  the  evaluators  to  technically  penetrate  the  proposals 
and  to  discern  if  and  how  much  the  proposer  grasps  and  is  proficient  with  the  intent, 
purpose,  and  method  of  —  and  possesses  the  knowledge  for  —  the  successful  provision  of 
systems  and  services.  Using  these  factors  and  criteria,  the  Evaluation  Committee  can  and 
will  determine  if  the  proposer  is  merely  repeating  (or  paraphrasing  without  substantial 
independent  contributions  or  thought  process)  the  RFP  requirements  or  if  it  is  truly 
proficient  with  the  subject  matter  in  a  way  that  will  contribute  to  the  attainment  of  the 
RFP's  objectives. 


(8.5.4)  Credibility 

Proposers  should  be  very  careful  relative  to  the  provision  of  information  that  could  call  the 
credibility  of  their  proposal  into  question,  for  example,  implying  or  stating  that  systems  or 
services  or  significant  elements,  features,  benefits  of  systems  or  services  were  operational 
for  periods  of  time  when  they  were  not.  The  proposers  should  clearly  indicate  availability 
versus  usage  in  a  production  environment  or  of  only  partial  capabilities  of  core  systems  and 
taking  credit  as  if  the  system  usage  involved  all  elements  for  long  periods  of  time.  Also, 
proposers  should  be  very  careful  relative  to  identifying  usage  at  certain  volume  or 
transaction  levels  if  the  usage  at  these  stated  levels  were  not  for  the  major  portion  of  time 
covered  by  the  dates  reflected  in  a  response  or  on  a  form. 


(8.5.5)  Recognition  of  Hybrid  PVPMISS  Environments 

The  City  recognizes  that  PVPMISS'  for  major  cities  with  high  parking  ticket  issuance 
levels  in  many  cases  tend  to  be  unique  and  hybrid.  Further,  each  distinct  major  PVPMISS 
client  tends  to  insist  upon  unique  features,  specifications,  and  other  requirements  due  to  a 
number  of  factors,  such  as:  state  and  local  laws,  ordinances,  regulations;  institutional 
reasons;  organizational  orientation;  etc.  For  this  reason,  the  proposers  are  expected  to 
provide  responses  that  demonstrate  and  substantiate  the  flexibility  of  their  systems  and 
operations  as  well  as  their  ability  to  deliver  the  systems  and  services  required  by  this  RFP 
with  the  extremely  high  quality  and  performance  levels  demanded  by  the  City. 
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(8.5.6)  Not  a  Systems  Development  RFP 


Proposer's  are  advised  to  note  that  this  RFP  is  for  the  provision  and  operation  of  a  'turnkey' 
(ready  to  operate  in  a  production  environment)  PVPMISS,  with  all  required  systems  and 
services  fully  operational  on  July  1,  2010,  along  with  the  delivery  of  extremely  high  quality 
and  performance  levels  demanded  by  the  City.  The  City  has  no  desire  to  procure  a 
PVPMISS  that  could  cause,  due  to  significant  development  requirements  and  exposure  to 
the  uncertainties  inherent  in  any  such  process,  risk  or  disruption  to  the  City's  current  level 
and  quality  of  enforcement,  customer  service/public  responsiveness,  processing 
components  and  efforts,  and  collection  rates  and  revenue,  or  that  could  cause  an  increase  in 
operational  and  other  costs,  increased  rates  of  inquiries  and  disputes,  or  a  loss  of  confidence 
from  the  public. 


This  RFP  is  not,  and  should  not  be  considered  in  anyway,  an  RFP  for  the  development  of  a 
PVPMISS  for  the  City.  Notwithstanding  expected  levels  of  PVPMISS  customization 
required  to  satisfy  the  City's  needs,  it  is  contrary  to  the  best  interests  of  the  City  to  become 
involved  in  the  (substantive)  development  of  a  PVPMISS,  or  with  a  situation  in  which  the 
capabilities  or  lack  of  important  elements  or  features  of  a  PVPMISS  would  require  the  City 
to  wait  for  and  undergo  time-consuming  and  potentially  costly  development  or  modification 
of  the  proposer's  PVPMISS  in  order  to  achieve  acceptable  levels  of  quality  and 
performance.  The  City  has  a  limited  capability  to  commit  and  utilize  scarce  staff  and/or 
financial  resources  to  enhance,  modify,  fine  tune,  test  or  debug  a  PVPMISS  to  achieve  the 
quality  and  performance  levels  demanded  by  the  City.  Therefore,  the  capability  and 
flexibility  of  a  proposer's  PVPMISS  is  especially  important  to  the  City. 


The  system  requirements  and  functional  specifications  presented  in  the  RFP  are  extremely 
detailed  and  comprehensive  and  have  been  articulated  to  the  greatest  extent  possible.  The 
City  has  not  provided,  and  cannot  provide,  detailed  technical  system  analysis  or  designs  or 
formal  technical  specifications  for  the  applications  —  otherwise,  the  City  would  have  no 
need  to  issue  this  particular  RFP.  In  this  regard,  the  City  looks  to  the  proposals  to  elaborate 
upon  the  requirements  and  submit  documentation,  user  guides,  narrative  and  pictorial 
reader  friendly  descriptions,  criteria  and  condition  statements,  etc.  Further,  notwithstanding 
expected  user-level  input  or  direction  from  the  City,  proposals  which  condition  the 
provision  of  system  or  system  elements  upon  the  provision  of  specifications  from  the  City 
shall  not  be  favorably  received.  The  City  has  already  provided  such  specifications  in  great 
detail,  and  to  the  best  of  its  ability,  in  the  RFP. 
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(8.5.7)  Alternatives 


Proposers  may  state  and  present  alternatives  to  the  Scope  of  Services  specifications  and 
requirements  for  systems  and  services  which  they  believe  offers  equivalent  services, 
performance  and  benefits  by  some  other  means,  as  long  as  they  are  consistent  with  Chapter 
30B  of  the  Massachusetts  General  Laws,  and  the  Evaluation  Committee  at  its  sole 
discretion  will  review  and  consider  whether  the  proposed  alternative  achieves  equivalent 
performance.  In  the  event  that  any  alternatives  are  presented  by  a  proposer,  said 
alternatives  shall  be  clearly  prefaced  in  the  proposal  with  the  capitalized  word 
'ALTERNATIVE'. 


(8.5.8)  Exceptions  to  RFP 

The  City  reserves  the  right  to  accept  exceptions  to  the  specifications  and  conditions 
contained  in  the  RFP,  as  long  as  they  are  consistent  with  Chapter  30B  of  the  Massachusetts 
General  Laws.  Exceptions  to  the  RFP  are  defined  as  exceptions  to  the  Scope  of  Services  or 
other  part  of  the  RFP  by  the  proposer  as  to  the  intent  and  word  of  any  portion  of  this  RFP. 
All  exceptions  to  the  RFP  will  be  included  as  an  integral  part  of  the  proposer's  formal 
Proposal  and  will  clearly  state  the  variation  between  the  affected  portion  of  the  RFP  and  the 
proposer's  exception.  The  exceptions  will  be  introduced  as  a  separate  section  of  the 
Proposal  in  the  following  manner.  The  'offending'  text  (or  the  text  in  question)  from  the 
RFP  will  be  clearly  identified  by  the  proposer.  Reasons  or  justification  explaining  the 
exception  will  follow.  Lastly,  a  proposed  alteration  with  substantial  detail,  description  and 
discussion  of  the  benefits,  etc.,  and  a  description  of  how  the  alternative  achieves  equivalent 
service  and  performance,  must  be  included.  In  the  event  that  any  exception  will  affect  more 
than  one  (1)  item  or  will  affect  the  overall  delivery,  provision,  or  operation  of  the  item,  the 
full  effect  of  such  exception  shall  be  fully  and  completely  explained. 
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SECTION  9.0 


INSTRUCTIONS  FOR  THE  COMPOSITION  OF  THE 
PRICE  PROPOSAL  AND  INFORMATION 
RELATING  TO  THE  EVALUATION  THEREOF 
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SECTION  9.0 

INSTRUCTIONS  FOR  THE  COMPOSITION  OF  THE 
PRICE  PROPOSAL  AND  INFORMATION 
RELATING  TO  THE  EVALUATION  THEREOF 


(9.1)  Introduction 

This  section  of  the  RFP  provides  instructions  to  Proposers  and  copies  of  the  forms  to  be 
used  for  the  submission  of  the  Price  (Non-Technical)  Proposal.  Remember,  the  Price 
Proposal  must  be  separated  from  the  Non-Price,  i.e.,  Technical,  Proposal  as  set  forth  in  this 
RFP. 

The  terms  'price',  'cost',  'price  quote',  etc.,  shall  be  synonymous  with  the  term  'price'. 

Comprehensive  Per  Ticket  Price  must  be  addressed  by  Proposers  which  is  described  and 
explained  in  detail  in  the  RFP  Scope  of  Services  and  on  the  pages  that  follow. 


(9.2)  'Comprehensive  Per  Ticket  Price'  to  be  Based  Upon  a 
Maximum  of  Three  (3)  Contract  Years 

The  'Comprehensive  Per  Ticket  Price'  set  forth  above  and  explained  in  this  section  of  the 
RFP  shall  be  based  upon  a  maximum  of  three  (3)  Contract  years,  i.e.,  from  July  1,  2010  to 
June  30,  2013. 

(9.3)  Uniform  Price  Evaluation  Format 

To  facilitate  comparison  of  Price  Proposals  and  to  ensure  an  accurate  and  fair  comparison 
of  prices,  it  is  expressly  required  that  Proposers  adhere  to  the  instructions  and  conditions  set 
forth  herein. 


(9.4)  Proposers'  Examination  of  the  RFP  and  Responsibility  of 
Proposers  to  Calculate  Their  Prices 

Proposers  are  reminded  of  their  obligation  to  thoroughly  examine  and  familiarize 
themselves  with  all  information,  conditions,  materials,  specifications,  requirements,  etc., 
contained  in  this  RFP.  This  RFP  process  provides  extremely  detailed  information  and  any 
necessary  clarification  opportunities  regarding  the  responsibilities  of  the  City  and  the 
Contractor  (Vendor)  from  which  proposers  are  required  to  calculate  their  costs/prices  and 
arrive  at  an  equitable  exchange  of  value  for  service. 
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(9.5)    Prices  That  are  to  be  Evaluated  on  a  Fixed  Ticket  Issuance 
Level  of  1.7  Million  Tickets 


(9.5.0)  Price  quote  for  the  'Comprehensive  Per  Ticket  Price' 

Price  quote  for  the  'Comprehensive  Per  Ticket  Price'  shall  be  evaluated  based  upon  a 
violation  ticket  issuance  level  of  one  million  and  seven  hundred  thousand  (1,700,000) 
tickets  per  City  of  Boston  fiscal  year.  Proposers  are  required  to  provide  price  quotes  for 
these  items  based  upon  an  anticipated  issuance  level  of  1.7  million  violations.  Proposers 
shall  assume  90%  Hand-Held  Device  tickets  and  10%  Non-Hand-Held  Device  tickets 
anticipated  issuance  (i.e.  1,550,000  HHD  tickets  and  150,000  N-HHD  tickets). 

It  is  important  to  note  that  compensation  paid  to  the  Successful  Proposer  (Contractor)  for  all 
of  these  billable  items  shall  be  based  only  upon  violations  actually  issued,  data  entered, 
updated  to  the  computer  system  (posted  to  the  'Master  File')  or  microfilmed.  The  above  1.7 
million  issuance  level  is  anticipated  and  is  based  upon,  among  other  things,  historical 
parking  ticket  issuance  levels.  Actual  issuance  levels  for  the  five  most  recent  fiscal  years 
(July  1  thru  June  30)  are: 


FY09  1,599,351 

FY08  1,524,860 

FY07  1,527,061 

FY06  1,610,988 

FY05  1,549,559 


Also,  with  regard  to  the  Comprehensive  Per  Ticket  Price  that  is  to  be  paid  to  the  Contractor, 
in  the  event  that  ticket  issuance  exceeds  1.7  million  violations  for  any  fiscal  year,  then  the 
'Comprehensive  Per  Ticket  Price'  in  effect  for  that  year  shall  be  adjusted  downward 
(discounted)  by: 

ten  percent  (10%)  of  the  amount  of  the  Comprehensive  Ticket  Price  in  effect 
for  that  fiscal/contract  year  for  each  and  every  violation  ticket  issued  (and 
updated  to  the  computer  system)  in  excess  of  1.7  million,  i.e.,  one  million  and 
seven  hundred  thousand  and  one  (1,700,001),  and  up  to  2.1  million  (two  million 
and  one  hundred  thousand)  tickets,  and 

twenty  percent  (20%)  of  the  amount  of  the  Comprehensive  Ticket  Price  in 
effect  for  that  fiscal/contract  year  for  each  and  every  violation  ticket  issued  (and 
updated  to  the  computer  system)  in  excess  of  2.1  million,  i.e.,  two  million  and 
one  hundred  thousand  and  one  (2,100,001),  etc.,  tickets. 

Also,  all  of  these  prices  shall  remain  fixed  as  they  relate  to  issuance  levels  (and  thus  to 
the  subsequent  need  for  these  issuance  related  services),  regardless  of  issuance  levels  in 
excess  of,  or  below,  1.7  million  (one  million  and  seven  hundred  thousand)  violations. 
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(9.6)  Section  Left  Blank  Intentionally 


(9.7)  Note  to  Proposers  Regarding  the  Two  Different  Volume  Categories  of  Prices 

Proposers  should  note  that  the  aforementioned  volume  categories  of  prices  (i.e.,  '1.7 
million  volume'  and  'other  than  1.7  million  volume')  are  set  forth  to  reflect  the  anticipated 
volumes  relative  to  the  price  items  within  each  volume  category.  All  prices  shall  be  added 
to  establish  a  'grand  total'  price/cost  and  shall  not  be  evaluated  separately. 


(9.8)    Singular  (Base  Contract  Year)  Price  Quotes  for  All  Price  Items  to  be  Automatically 
Adjusted  Annually  via  the  CPI 

The  City  requires  a  single,  i.e.,  one,  price  quote  for  each  and  every  requested  item. 

These  price  quotes  shall  be  the  cost/price  charged  to  the  City  during  the  first  (base)  year  of 
the  three  year  contract  to  be  entered  into  pursuant  to  this  RFP. 

In  the  event  that  the  Contract  entered  into  pursuant  to  this  RFP  is  extended  beyond  its  initial 
twelve  (12)  month  period,  or  beyond  any  following  twelve  (12)  month  periods,  the  fees  for 
services  performed  hereunder  shall  be  automatically  adjusted  on  the  basis  of  the  lesser  of 
either  an  increase  in  the  cost  of  living  which  occurred  during  the  then  expiring  period  of 
this  Agreement  or  two  and  three  quarter  percent  (2.75%).  Such  cost  of  living  increase  shall 
be  a  percentage  equal  to  the  percentage  increase  in  the  Consumer  Price  Index  (CPI)  for 
Boston-Brockton-Nashua,  MA-NH-ME-CT,  all  Urban  Consumers,  all  items  less  food  and 
energy  (Core  CPI)  for  the  month  of  January  immediately  preceding  the  renewal  date  as 
compared  to  the  Index  for  the  same  month  in  the  prior  year,  but  such  increase  shall  in  no 
event  exceed  two  and  three  quarter  percent  (2.75%). 


(9.9)    Section  Left  Blank  Intentionally 
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(9.10)  Summary  Evaluation  Methodology  for  All  Prices 
Considering  Three  Full  Contract  Years 

The  summary  evaluation  of  all  price  items  shall  utilize  the  aforementioned  single  price/cost 
figures  which  shall  be  provided  by  Proposers  via  the  required  price  forms.  In  this  way,  a 
'first  contract  year'  (base  year)  price  shall  be  established  for  each  price  item  along  with  a 
single  total  price  for  each  price  form  sheet.  The  single  total  prices  for  each  price  form  sheet 
shall  be  added  to  calculate  a  summary  base  price  of  all  items  for  the  first  (base)  year  of  the 
contract  to  be  entered  into,  with  the  exception  of  secondary  collection  fees. 

In  order  to  calculate  subsequent  contract  renewal  rates,  the  City  will  most  likely  assume  a 
'worst  case  scenario'  in  terms  of  inflation,  i.e.,  the  increase  to  the  CPI  and  thus  to  the  quoted 
PVPMISS  rates.  Therefore  it  is  expected  that  a  maximum  contract  renewal  increase  rate  of 
two  and  three  quarter  percent  (2.75%)  will  be  employed  in  the  calculation  of  the  new 
PVPMISS  rate(s)  for  each  contract  renewal  year.  This  shall  be  accomplished  by  adding  two 
and  three  quarter  percent  of  the  expiring  contract  rates  to  the  actual  (whole)  expiring  rates 
to  yield  a  new  (renewal)  rate. 

In  regard  to  the  number  of  years  that  will  be  employed  to  evaluate  prices  out  of  the 
maximum  possible  three  contract  years,  the  City  will  assume  that  a  full  three  contract  years 
will  be  realized  so  as  to  calculate  the  maximum  possible  compensation  obligation  of  the 
City. 


(9.11)    Definition  and  Overview  of  Price  Categories 


(9.11.0)  Introduction 

The  Proposers'  responsibilities  as  they  relate  to  price  categories  are  described  and  explained 
in  detail  in  the  RFP  Scope  of  Services  and  Appendixes  to  the  RFP.  However,  for  added 
clarity  and  convenience,  they  are  summarized  on  the  following  pages. 

Also,  with  regard  to  the  'Comprehensive  Per  Ticket  Price',  additional  information  is 
provided  as  it  relates  to  certain  cost/price  areas. 


(9.11.1)  Definition  and  Overview  of  Comprehensive  Per  Ticket  Price 

The  'Comprehensive  Per  Ticket  Price'  shall  encompass  ALL  areas  of  Contractor  (Vendor) 
responsibility  not  included  in  the:  'Hand-Held  Device  per  ticket  price'  and  the  'Non-Hand- 
Held  per  ticket  price'. 

The  scope  of  this  RFP  for  this  cost  item  must  be  carefully  considered  by  Proposers!  Only 
in  this  manner  can  the  objectives  and  requirements  of  this  RFP  be  assured  of  being 
achieved. 
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For  illustrative  purposes  only,  without  in  any  way  relieving  a  proposer  of  its  responsibility 
to  determine  its  costs/prices  based  upon  this  RFP  process  and  its  costs/prices  relevant  to  this 
RFP,  below  is  a  sample  listing  of  the  costs  that  the  City  anticipates  the  Contractor  (Vendor) 
to  incur  in  providing  the  services  required  in  this  RFP.  IN  NO  WAY  SHOULD  THIS 
LISTING  BE  CONSTRUED  TO  REPRESENT  ALL  COSTS  THAT  A  PROPOSER 
SHOULD  CALCULATE  INTO  ITS  PRICE  PROPOSAL.  In  addition  to  the  above  stated 
position  of  the  City  that  the  proposer  is  inherently  responsible  for  its  price  calculations,  the 
City  understands  that  different  PVPMISS'  may  well  involve  different  price  considerations 
specific  to  a  particular  proposal.  Further,  many  of  the  items  listed  below  are  set  forth  in  a 
general  manner  and  the  City  does  not  in  any  way  represent  that  it  is  fully  aware  of  an 
inventory  of  required  sub-items  under  a  particular  item.  For  example,  for  the  item 
'Contractor  Boston  facility(ies)  and  equipment',  this  listing  does  not  address  possible  sub- 
items  such  as  Remote  Job  Entry  (RJE)  equipment,  data  lines,  ticket  counting  machines, 
OCR  payment  processing  machines,  micro-computers,  copying  machines,  telephone 
systems,  etc.  Finally,  to  provide  a  complete  listing  of  costs  would  involve  the  substantial 
repeating  of  the  Scope  of  Service  requirements  and,  for  that  reason,  items  such  as  'Provision 
of  Complete  Services  to  all  Tickets  on  the  Database'  are  not  expressly  listed. 

Listing: 

Conversion  costs 
Installation  costs 
Performance  Bond 
Insurance  costs 

Contractor  Boston  facility(ies)  and  equipment 

-    Personnel  (e.g.,  receipt  of  ticket  personnel,  lockbox  personnel,  payment  processing 
personnel,  bounced  check  processing  personnel,  control  and  reconciliation 
personnel,  systems  analysts/  programmers/etc.  personnel,  supervisory  personnel, 
administrative  personnel,  telecommunications  personnel,  micro-computer 
programmer,  etc. 

PVPMISS  and  all  related  software  programs,  all  related  hardware  and  all  related 
telecommunication 

Maintenance  of  software  and  changes  and  modifications  to  requirements 

Maintenance  of  hardware  and  updating  of  hardware 

Network  capability  and  management 

Data  center(s)  computer  hardware  and  equipment 

Mainframe/CPU  processing  and  all  client  server  networking 

Mainframe  to  network  (LAN/WAN)  interface 

Maintenance  of  Master  File  backup  files 
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Off-site  (from  data  center)  storage  of  Master  File  backup  files 

Alternate/back-up  data  center  site  (alternative  processing  arrangements) 

All  PVPMISS  systems  and  hardware  including  computer  terminals,  printers  and 
workstations  for  the  Vendor's  and  the  City's  use 

Data  center(s)  network  capability,  management  and  interface  requirements 

Local  office  network  capability,  management  and  interface  requirements 

Installation  and  configuration  (and  possible  re-configuration)  of  terminals  and 
printers  at  various  City  sites 

Miscellaneous  equipment  such  as  'housing'  cabinets  for  network  equipment  located 
at  City  Hall 

Provision  and  maintenance  of  Voice  Response  (Telephone)  System  including  all 
hardware,  software  and  telecommunications 

Provision  of  Pay-By-Phone  VRS  application 

Provision  of  Pay-by- Web  application 

Microfilming  of  lockbox  payments  (checks)  —  microfilming  and  storage  of  tickets  and 
ticket  related  documents 

Post  office  boxes  (currently  three) 

RMVs  name  and  address  requests  (none  of  these  costs  are  reimbursable) 

Optical  disk/magnetic  tape/cartridge/or  other  medium  storage 

Bi-weekly  boot  book  download 

Data  communication  telephone  lines 

MA  RMV  interface  data  communication  lines 

Mail-house  related  services  (such  as  separating  notices,  inserting  notices  and  return 
envelopes,  etc.) 

Daily  courier  services  (for  Post  Office  pick-up,  bank  deposits,  Transportation 
Department  runs,  keypunch  and  microfilm  vendor  runs,  MA  RMV  runs,  etc.) 

Computer  output  paper  and  printing  ribbons/cartridges 

Microfilm  reader/printer 

Secondary  collections  postage  and  other  costs 

Possible  travel  costs  of  Contractor  personnel 
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Document  storage  (base  requirement  of  2,000  cubic  feet  with  yearly  increases  of 
approximately  300  additional  cubit  feet) 

Quarterly  archive  file  transfer 

Complete  imaging/workflow  system  including  all  hardware,  software, 
telecommunication  and  other  related  items 

Internet/  www/  e-commerce  applications 


(9.11.1.0)   'Comprehensive  Per  Ticket  Price'  Note:  All  Systems  and  Services  to  be 
Included  in  the  Stated  Price 

Any  and  all  RFP  systems,  services,  items  or  responsibilities,  or  components  thereof,  which 
do  not  explicitly  identify  the  City  as  the  entity  responsible  for  the  provision  of  those 
systems,  services,  items  or  responsibilities  and  the  costs  therein  shall  be  the  responsibility 
of  the  Contractor. 

Also,  per  the  provisions  set  forth  in  section  4.2  (Changes  to  Specifications  and 
Requirements),  it  shall  be  clearly  understood  that  the  City  will  not  entertain  reimbursable 
'change  orders'  or  other  charges  for  software  computer  system  changes  involving  the 
PVPMISS.  All  costs  relating  to  changes,  modifications  or  enhancements  to  the 
PVPMISS  computer  environment  are  the  responsibility  of  the  Contractor. 

If  a  proposer  is  unclear  as  to  any  responsibility  in  the  RFP  it  is  the  proposer's  responsibility 
to  seek  clarification  prior  to  the  submittal  of  its  proposal. 


(9.11.1.1)  'Comprehensive  Per  Ticket  Price'  Note:  MA  RMV  Costs 

The  City's  ability  to  obtain  timely  and  accurate  registrant  names  and  addresses  are  critical 
to  the  success  of  the  PVPMISS.  The  Vendor  will  be  required  to  obtain  registrant  data,  at  its 
cost,  by  means  determined  by  the  City.  The  Vendor  must  be  prepared  and  have  the 
capability  to  obtain  registrant  data  by  different  options.  The  City  will  select  the  option  that 
it  believes  will  produce  the  best  results  based  on  the  City's  assessment  of  programmatic 
effectiveness.  The  City  desires  and  will  likely  require  the  Vendor  to  obtain  registrant  data 
by  on-line  access  to  the  RMV's  database  when  this  option  becomes  available.  However, 
until  this  option  becomes  available,  the  Vendor  will  likely  be  directed  to  obtain  registrant 
data  from  the  RMV  by  purchasing  routine  tapes  that  are  currently  generated  by  the  RMV 
every  four  (4)  to  six  (6)  weeks  or  by  requesting  and  purchasing,  via  tape  or  other  City 
approved  media,  registrant  data  from  the  RMV  on  a  weekly  basis.  The  Vendor  must,  at  a 
minimum,  have  the  ability  to  obtain  registrant  data  by  these  means. 
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(9.11.1.2)   'Comprehensive  Per  Ticket  Price'  Note:  Banking  Services  Costs 

Note:  The  City  will  pay  for  and  contract  directly  with  the  bank  for  the  banking 
services. 


(9.11.1.3)   'Comprehensive  Per  Ticket  Price'  Note:  Postage  Costs 

The  City  will  only  assume  the  cost  of  postage  for  dunning  and  On-Line  Claims  Processing 
System  correspondence  notices,  Resident  Parking  notices  and  Abandoned  Vehicle  notices, 
and  shall  maintain  an  account  at  the  U.S.  Postal  facility  for  this  purpose.  However,  with 
regard  to  any  secondary  collection  services,  costs  for  postage  (and  printing  of  notices/ 
envelopes/  processing  forms)  are  the  responsibility  of  the  Vendor  selected  for  secondary 
collections. 


(9.11.1.4)   'Comprehensive  Per  Ticket  Price'  Note:  Secondary  Collections 

As  set  forth  in  the  section  4.35  (Secondary  Collections)  of  this  RFP,  the  Contractor  shall 
receive  thirty-four  percent  (34%)  of  the  revenue  collected  from  those  eligible  tickets. 


(9.11.2)  Section  Left  Blank  Intentionally 


(9.11.3)  Section  Left  Blank  Intentionally 


(9.12)  Note  Regarding  the  Same  Subcontractor  for  Different  Proposals 

In  the  event  that  subcontractors  for  any  of  the  above  services  are  identified  by  a  proposer  as 
providing  that  service  for  that  particular  proposer's  proposal,  said  subcontractor  is  not  to  be 
prohibited  by  the  terms  of  this  RFP  from  joining  with  another  proposer  in  the  submittal  of 
that  different  proposal. 
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(9.13)   Instructions  to  Proposers  Regarding  the  Completion  of  the  Price  Forms, 
i.e..  the  'Price  Proposal' 

The  'Price  Proposal'  shall  consist  of  the  'Price  Forms'  set  forth  on  the  following  pages. 

Based  upon  the  information  provided  in  the  preceding  pages,  in  combination  with  the 
'self-explanatory'  nature  of  the  Price  Forms,  provide  all  requested  price  quotes  for  the 
following  forms: 

Form:  PF1 

COMPREHENSIVE  PER  TICKET  PRICE 
Form:  PF2 

GRAND  TOTAL  PRICE  FOR  YEAR  1  (BASE  YEAR) 

Facsimiles  of  the  forms  may  be  used.  Also,  at  the  request  of  a  proposer,  the  City  shall 
provide  additional  copies  of  the  Price  Forms. 

Form  PF1,  COMPREHENSIVE  PER  TICKET  PRICE,  form,  shall  be  completed  by 
Proposers  for  each  Hand-Held  Ticket  Writing  Device  proposed,  for  a  maximum  of  three 
(3)  different  devices.  Proposers  may  propose  a  maximum  of  three  (3)  different  devices 
for  the  City's  consideration  and  may  therefore  propose  three  (3)  different  'Hand-Held 
Device  Per  Ticket'  prices.  In  such  cases,  Proposers  should  also  submit  Grand  Total  Price 
Forms  (Form  PF2,  'GRAND  TOTAL  PRICE  FOR  YEAR  1  (BASE  YEAR')  for  each 
Hand-Held  Device  proposed  up  to  a  maximum  of  three  (3)  different  devices. 
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PRICE  FORM  PF1 
COMPREHENSIVE  PER  TICKET  PRICE 

Name  of  Proposer: 


a)  UNIT  PRICE 

TOTAL  YEAR  1  (BASE  YEAR)  PRICE 

Base  Comprehensive  Per  Ticket  Price  x  1,700,000  :  $ 
Express  price  in  words: 
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PRICE  FORM  PF2 


*  GRAND  TOTAL  PRICE  FOR  YEAR  1  (BASE  YEAR) 


Name  of  Proposer: 


Add  the  five  categories  of  'Total  Year  1  (Base  Year)  Price'  to  arrive  at  the  'Grand  Total 
Price  For  Year  1  (Base  Year)'. 


Form:  PF1 

Item:  COMPREHENSIVE  PER  TICKET  PRICE 


Total  Base  Year  Price:  $ 
Express  price  in  words: 


GRAND  TOTAL  PRICE 
FOR  YEAR  1  (BASE  YEAR)  =  $ 
Express  price  in  words: 

*  The  grand  total  does  not  include  secondary  collections. 
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SECTION  10.0 
SUBMISSION  OF  THE  COMPLETE  PROPOSAL 
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SECTION  10.0 
SUBMISSION  OF  THE  COMPLETE  PROPOSAL 


(10.1)  Introduction 

Sections  8.0  and  9.0  provide  instructions  relative  to  the  composition  and  contents  of  the 
non-price  (technical)  proposal  and  the  price  proposal,  respectively.  This  section  of  the  RFP 
provides  instructions  for  the  format  and  submission  of  the  complete  proposal. 


(10.2)  Number  of  Proposal  Copies  to  be  Submitted 

Proposer  will  submit  one  original  technical  (non-price)  proposal,  one  original  price 
proposal,  five  copies  of  the  technical  (non-price)  proposal,  and  one  copy  of  the  price 
proposal. 


(10.3)  Requirements  of  Format 

To  facilitate  the  evaluation  process  each  respondent  must: 
Provide  proposals  in  the  format  requested. 

Organize,  tab,  and  label  proposals  to  include  section  number  and  section  name 
exactly  as  outlined  below. 

Provide  all  other  data  not  specifically  requested  in  the  Proposal  Format  outlined 
below. 


(10.4)  Proposal  Format 

Proposals  shall  be  provided  in  accordance  with  the  format  set  forth  below. 

A)  The  Cover  Letter  -  The  cover  letter  provided  with  the  RFP  should  be  completed  and 
signed  by  an  individual  authorized  to  represent  and  contractually  bind  the  proposer. 
This  letter  must  contain  the  name  and  address  of  the  corporation  or  business  structure 
submitting  the  proposal  and  the  name,  address,  telephone  number  and  title  of  the 
authorized  person. 


B)  Table  of  Contents  -  All  pages  must  be  numbered. 
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C)  Executive  Summary  -  An  outline  of  the  proposer's  general  approach  along  with  a  brief 
description  of  the  significant  points  of  the  proposal. 


D)  Minimum  Evaluation  Criteria  -  Responses  to  the  minimum  evaluation  questionnaire. 
Written  validation  of  proposer  responses  may  be  requested  at  any  time  during  this 
process  by  the  City. 


E)   Response  to  the  Scope  of  Services  -  Responses  to  the  Scope  of  Services  as  set  forth  in 
Section  8.0  of  this  RFP.  With  regard  to  the  provision  of  'documentation'  as  described 
in  Section  8.0,  this  material  may  be  submitted  as  a  separate  document(s)  clearly  labeled 
'System  Documentation'. 


F)   Detailed  Discussion  of  Exceptions  or  Conditional  Compliance  with  the  RFP  -  A 
detailed  discussion  of  any  exception  or  conditional  compliance  with  the  RFP  as  set 
forth  in  Section  8.0  of  this  RFP.  Remember  that  a  summary  (versus  detailed)  statement 
of  any  conditional  or  exception  item  would  appear  in  the  proposers'  provision  of  'E' 
above. 


G)  Responses  to  the  Evaluation  Forms  and  Questionnaires  -  Responses  to  the  Evaluation 
Forms  and  Questionnaires  as  set  forth  in  Section  8.0  of  this  RFP.  NOTE:  Proposers 
may  reproduce  or  use  a  facsimile  of  forms  and  questionnaires,  or  may  request 
additional  copies  from  the  City. 


H)  Additional  Materials  -  Additional  materials  which  may  be  submitted  by  the  proposer 
for  review  and  analyses. 

I)  Price  Proposal  -  The  price  proposal  shall  be  submitted  in  accordance  with  the 
information  provided  in  section  9.0  of  the  RFP  and  shall  be  comprised  of  price  forms 
PF1  through  PF4. 

The  price  proposal  must  be  separated  from  the  non-price  (technical)  proposal  and  must 
be  enclosed  in  a  sealed  package  or  envelope. 

The  price  forms/sheets  must  provide  the  precise  level  of  detail  requested  on  the  forms 
provided.  NOTE:  Proposers  may  reproduce  or  use  a  facsimile  of  price  forms,  or  may 
request  additional  copies  from  the  City. 

The  City  will  require  firm  price  proposals  for  all  aspects  of  the  provision  and  operation 
ofaPVPMISS 
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(10.5)  Time  and  Date  for  Receipt  of  Proposals 


Proposer  responses  will  be  due  on  Wednesday.  February  17,  2010  by  12:00  Noon,  at  the 

Office  of  the  Parking  Clerk,  Room  224,  One  City  Hall  Plaza,  Boston,  MA  02201.  The  City 
will  not  accept  any  proposals  submitted  after  the  date  and  time  specified  herein. 


(10.6)  Address  to  Which  Proposals  are  to  be  Delivered 

The  proposer  will  deliver  its  proposal  executed  to  the  following  address: 

Mr.  Thomas  J.  Tinlin 
Commissioner/Parking  Clerk 
c/o/  Ms.  Gina  Fiandaca 
Director 

Boston  Transportation  Department/Office  of  the  Parking  Clerk 
One  City  Hall  Plaza  -  Room  224 
Boston,  MA  02201 

Any  proposals  received  after  the  designated  time  and  date  of  opening  will  not  be  accepted 
and  will  be  returned  to  the  originating  address  unopened. 


(10.7)  Packaging  of  Proposals 

Envelopes  containing  proposals  must  be  sealed  and  clearly  marked  in  large  letters 
"PROPOSAL  FOR  THE  PROVISION  AND  OPERATION  OF  A  PARKING 
VIOLATION/PARKING  MANAGEMENT  INFORMATION  SERVICES  SYSTEM 
(PVPMISS)". 

The  response  will  consist  of  a  sealed  Proposal  Package  which  will  contain  the  original 
technical  (non-price)  proposal  (accompanied  by  a  proposal  deposit  in  the  amount  of  twenty- 
five  thousand  dollars  [$25,000]  and  seven  copies  of  technical  (non-price)  proposal,  and  the 
original  sealed  price  proposal  and  one  sealed  copy  of  the  price  proposal,  and  shall  be 
delivered  to  the  above  address.  The  proposal  deposit  may  be  either  a  certified  check  drawn 
on,  or  a  treasurer's  or  cashier's  check  issued  by,  a  responsible  bank  or  trust  company  and 
made  payable  to  the  City  of  Boston,  or  a  proposal  bond  issued  by  a  surety  company 
qualified  to  do  business  in  the  Commonwealth  of  Massachusetts  and  satisfactory  in  form  to 
the  Parking  Clerk. 

Non-original  proposals,  i.e.,  proposal  copies,  may  be  photocopies.  Please  note,  the 
proposer  must  submit  two  (sealed  and  clearly  labeled)  copies  of  the  cost  proposals  (i.e.,  the 
original  copy  and  one  duplicate  copy)  in  response  to  this  RFP.  As  previously  noted,  the 
original  cost  proposal  must  accompany  the  original  technical  proposal  as  a  separate  and 
sealed  document  and  must  be  clearly  marked  as  such. 


(10.8)  Mandatory  Separation  of  Price  and  Non-Price  Proposals 

Chapter  30B  requires  that  proposers  must  separate  price  and  non-price  (or  technical) 
proposals.  As  mentioned  in  this  RFP,  this  provision  must  be  strictly  adhered  to. 
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SECTION  11.0 
CONTRACT  TERMS  AND  CONDITIONS 
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SECTION  11.0 


CONTRACT  TERMS  AND  CONDITIONS 


Introduction 


This  section  of  the  RFP  contains  the  terms  and  conditions  of  the  contract  to  be  entered  into 
pursuant  to  this  RFP  between  the  City  of  Boston  and  the  Selected  Proposer. 

The  contract,  which  shall  be  referred  to  as  the  'PVPMISS  Contract',  shall  be  comprised  of 
the  following  sections: 


I.        The  complete  'REQUEST  FOR  PROPOSALS  (RFP)  FOR  THE  PROVISION 
AND  OPERATION  OF  A  PARKING  VIOLATION/  PARKING 
MANAGEMENT  INFORMATION  SERVICES  SYSTEM  (PVPMISS)' 


II.       The  Contractor's  Proposal  (submitted  in  response  to  the  RFP  in  the  form  accepted 
by  the  City) 


III.  Collection  of  Delinquent  (Secondary)  Parking  Ticket  Accounts  (sets  forth  the 
conditions  and  rate  of  compensation  to  the  Contractor  for  secondary/  backlog 
collections) 


IV.      Schedule  of  Fees  (categories  and  rates  of  compensation  as  determined  by  the 
sealed  price  proposal) 


V.       City  of  Boston  Standard  Contract  Terms  and  Conditions  (and  Various  Other 
Standard  City  of  Boston  Contract  Documents) 


VI.      Additional  Contract  Terms  and  Conditions  (includes  general  contract  provisions 
in  addition  to  the  City's  standard  contract  provisions) 


VII.     Signatory  Page. 
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PVPMISS  CONTRACT 


SECTION  I:  REQUEST  FOR  PROPOSALS  (RFP)  FOR  THE  PROVISION  AND 
OPERATION  OF  A  PARKING  VIOLATION/  PARKING  MANAGEMENT 
INFORMATION  SERVICES  SYSTEM  (PVPMISS). 


The  'REQUEST  FOR  PROPOSALS  (RFP)  FOR  THE  PROVISION  AND  OPERATION 
OF  A  PARKING  VIOLATION/  PARKING  MANAGEMENT  INFORMATION 
SERVICES  SYSTEM  (PVPMISS)'  shall  be  incorporated  in  its  entirety  by  reference. 
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PVPMISS  CONTRACT 


SECTION  II:  THE  CONTRACTOR'S  PROPOSAL  FOR  'THE  PROVISION 
AND  OPERATION  OF  A  PARKING  VIOLATION/  PARKING 
MANAGEMENT  INFORMATION  SERVICES  SYSTEM  (PVPMISS)' 


The  Selected  Proposer's  (Contractor's)  Proposal  submitted  in  response  to  the  'REQUEST 
FOR  PROPOSALS  (RFP)  FOR  THE  PROVISION  AND  OPERATION  OF  A  PARKING 
VIOLATION/  PARKING  MANAGEMENT  INFORMATION  SERVICES  SYSTEM 
(PVPMISS)'  shall  be  incorporated  in  its  entirety,  in  the  form  accepted  by  the  City,  by 
reference. 
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PVPMISS  CONTRACT 


SECTION  III:  COLLECTION  OF  DELINQUENT  (SECONDARY) 
PARKING  TICKET  ACCOUNTS 


The  Commissioner  of  Transportation/Parking  Clerk  ("the  Parking  Clerk")  may,  from  time 
to  time,  determine  at  his/her  discretion  that  certain  due  but  unpaid  parking  tickets  issued  in 
prior  calendar  years  are  to  be  assigned  to  the  Contractor  for  secondary  collection  efforts. 
The  Contractor  shall  undertake,  through  ethical  and  lawful  means  consistent  with 
Massachusetts  General  Laws  Chapter  93A,  and  any  and  all  other  laws  pertaining  to 
collection  activities,  to  collect  parking  ticket  fines  and  penalties  for  the  City  from  vehicle 
owners  and  operators  responsible  for  the  payment  of  those  fines  and  penalties.  It  is 
understood  that  effective  July  1,  2010,  subject  to  the  discretion  of  the  Parking  Clerk,  the 
assignments  shall  include,  at  a  minimum,  the  following  parking  ticket  accounts  for 
secondary  collection: 

a)  continuing  at  three  (3)  month  intervals  throughout  the  duration  of  this  Contract, 
such  parking  ticket  delinquent  accounts  in  addition  to  'b',  'c'  and 'd'  below  that 
have  aged  nine  (9)  months  from  the  date  of  issuance; 

b)  such  parking  ticket  delinquent  accounts  that  have  been  issued  to  out  of  state  (non- 
MA)  registrants  that  have  been  included  in  and  aged  ninety  (90)  days  from  the 
mail  date  of  a  third  out-of-state  dunning  notice; 

c)  such  parking  ticket  delinquent  accounts  that  have  been  issued  to  leased,  rental  and 
taxi  vehicles  that  have  been  included  in  and  aged  ninety  (90)  days  from  the  mail 
date  of  a  second  lease/  rental/taxi  vehicle  notice; 

d)  tickets  in  Non-Renewal  Status  that  have  aged  twenty-five  (25)  months  from  the 
date  that  the  non-renewal  mark  was  updated  to  the  database  in  the  cases  of 
registrations  that  are  subject  to  registration  renewal  every  two  years,  and  tickets  in 
Non-Renewal  Status  that  have  aged  thirteen  (13)  months  from  the  date  that  the 
non-renewal  mark  was  updated  to  the  database  in  the  cases  of  registrations  that  are 
subject  to  registration  renewal  annually. 

i)  Less  any  tickets  payable  as  a  result  of  the  seizure  of  a  vehicle  (Boot  & 
Tow); 

ii)  Less  any  specific  tickets  'marked'  for  non-renewal  of  driver's  license  or 
vehicle  registration  at  the  Massachusetts  Registry  of  Motor  Vehicles  that 
are  not  in  population 'd'  above. 

Proposers  should  be  aware  that  their  fee  will  not  include  any  payments  for  non-renewal 
fees  or  any  other  fees  or  other  charges  that  are  collected  and  directly  or  indirectly  remitted 
to  a  non-city  entity. 
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1. 


Collection  Activities: 


The  Contractor  shall  issue  a  series  of  computer  generated  notices  to  parking 
violators.  The  Contractor  shall  use  only  notices  approved  by  the  Parking  Clerk. 
All  collection  activities  shall  be  performed  in  compliance  with  Section  4.35  of  this 
RFP  and  with  applicable  provisions  of  the  Federal  Fair  Debt  Collection  Practices 
Act  and  Massachusetts  law.  The  Contractor  agrees  to  submit  to  the  City  for  its 
approval  all  forms  used  in  the  collection  process. 


2.  Payment: 

2.1  Invoicing  Procedure  -  The  City  anticipates  that  sufficient  funds  shall  be  available 
to  allow  payment  when  goods  are  delivered  and  services  rendered  by  the 
Contractor,  and  the  goods  and  services  are  accepted  by  the  City.  The  Contractor 
shall  bill  the  City  on  a  monthly  basis  as  provided  in  paragraph  2.2,  below,  in 
arrears  for  services  rendered  using  invoices  in  the  form  required  by  the  City.  The 
City  agrees  to  review  each  invoice  and  within  fourteen  (14)  days  after  its  receipt, 
either  approve  it  and  deliver  it  to  the  City  Auditor  and  Collector-Treasurer  for 
payment,  or  return  it  to  the  Contractor  with  a  statement  of  the  reasons  for  its 
rejection. 

The  Contractor  shall  provide  the  City  with  all  reasonable  and  normal 
documentation  required  by  the  City  to  approve  such  invoices;  and  by  giving  such 
approval  the  City  does  not  waive  the  right  to  subsequently  challenge  the  validity  of 
such  billings  and  to  charge  back  the  Contractor  for  excess  billings. 

2.2  Fees  -  The  Contractor  will  be  entitled  to  receive  from  and  shall  be  paid  by  the  City 
a  fee  equal  to  thirty-four  percent  (34%)  of  all  amounts  collected  on  delinquent 
accounts  less  amounts  decremented  due  to  appropriate  adjustments  including 
dismissals  and  checks  returned  for  insufficient  funds.  The  Contractor  shall 
provide  to  the  Parking  Clerk  billing  control  reports  which  specifically  document 
payment  made  on  specific  tickets  assigned  for  secondary  collection.  Source 
documents  must  also  be  available  for  review  by  the  Office  of  the  Parking  Clerk. 

2.3  Bank  Deposits  -  The  Contractor  shall  deposit  into  the  Parking  Clerk  of  Boston 
Mail  Collection  Account  at  the  Bank  serving  as  a  subcontractor  for  banking 
services  required  under  this  Agreement  all  payments  within  48  hours  after  receipt 
and  shall  provide  to  the  City  a  copy  of  each  deposit  slip.  Appropriate  adjustments 
shall  be  made  for  dismissals  and  any  invalid  check  or  checks  drawn  against 
insufficient  funds.  The  Contractor  shall  prepare  daily  and  provide  to  the  City 
monthly  fee  and  collection  reports  in  a  form  approved  by  the  City,  which 
accurately  sets  forth  the  fees  earned  each  month.  The  Contractor  shall  provide  to 
the  City  each  month  a  copy  of  the  bank  statement  for  the  bank  accounts.  In 
addition,  within  ninety  (90)  days  following  the  end  of  the  term  of  this  Agreement, 
the  Contractor  shall  assure  that  the  City,  or  its  duly  authorized  representatives, 
shall  have  access  during  normal  business  hours  to  any  books,  documents,  records, 
and  papers  retained  by  the  Contractor  which  the  City  reasonably  determines  are 
directly  pertinent  to  this  Agreement  for  the  purpose  of  making  an  audit  or 
examination,  and  of  taking  excerpts  and  transcripts.  Payment  of  the  Contractor's 
final  invoice  will  be  contingent  upon  the  aforementioned  audit  or  examination. 
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3.      Suspension  of  Collection  Activities: 


The  Contractor  will  suspend  collection  efforts  on  any  tickets  referred  for  collection 
immediately  upon  receipt  of  notice  from  the  Parking  Clerk  (written  or  telephonic). 
The  City  shall  not  be  liable  for  any  fees  on  suspended  tickets  except  for  fees  that 
result  from  prior  collection  efforts  on  the  suspended  tickets.  However,  the  City's 
liability  shall  be  only  for  a  period  of  ninety  (90)  days  after  the  date  of  suspension. 
The  City  will  notify  the  Contractor  of  any  payments  to  the  City  on  tickets  assigned 
to  the  Contractor  for  collection  and  of  any  hearings  held  or  other  actions  taken 
which  result  in  dismissal  or  reduction  of  tickets. 

If  the  Contractor  violates  any  law  of  the  Commonwealth  with  respect  to  the 
collection  of  debts,  and  specifically  the  relevant  provisions  of  G.L.  c.  93A,  or  if 
the  Contractor  shall  be  fined,  charged  or  penalized  by  the  federal  government, 
Commonwealth  of  Massachusetts,  City  of  Boston  or  any  of  their  departments, 
agents  or  officers  for  violations  of  either  the  provisions  of  federal  or  state  laws, 
rules  or  regulations  governing  collection  activities,  the  Contractor  shall  be 
considered  to  be  in  breach  of  this  Agreement,  and  this  Agreement  shall  be 
terminated  immediately  upon  notice  in  writing  by  the  Parking  Clerk  to  the 
Contractor.  Upon  termination  as  set  forth  above  the  City  shall  not  make  any 
further  payments  to  the  Contractor  and  all  documents  and  records  relating  to  the 
collections  undertaken  under  this  Agreement  by  the  Contractor  shall  immediately 
be  delivered  to  the  Parking  Clerk  and  the  City  shall  thereupon  pay  the  Contractor 
all  amounts  previously  earned  by  the  Contractor  less  what  the  Parking  Clerk  may 
reasonably  determine  to  be  the  City's  damages  as  a  result  of  said  termination. 


4.      Phase  Down  Period: 

If  the  Contractor  has  commenced  collection  efforts  on  any  tickets  prior  to  the  end 
of  the  term  of  this  Agreement,  the  Contractor  shall  only  be  entitled  to  fees  on 
ticket  payments  made  on  or  before  the  termination  date. 


5.      Collection  Activity  Records  And  Management  Reports: 

The  Contractor  shall  maintain  separate  books  and  records  on  the  tickets  assigned 
for  collection  and  shall  maintain  a  file  on  each  ticket  assigned  for  collection.  Each 
ticket  file  shall  contain  records  of  collection  efforts  made  by  the  Contractor  and 
any  other  pertinent  information.  The  foregoing  shall  be  available  at  all  times  for 
inspection  and  audit  by  the  City  upon  prior  written  notice  to  the  Contractor. 

The  Contractor  will  produce  for  the  City  monthly  management  reports  on  an 
established  basis  as  mutually  agreed  upon.  These  reports  will  outline  the  specific 
tickets  identified,  violation  notice  data,  collections  received  and  other  similar 
accounting  data. 


6.      Secondary  Collection  Activity  Costs  -  the  Contractor  shall  bear  all  costs  (i.e., 

notice  and  envelope  printing,  postage,  processing  costs,  etc.)  associated  with  their 
specific  collection  efforts  on  assigned  accounts. 
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PVPMISS  CONTRACT 


SECTION  IV:  SCHEDULE  OF  FEES 


Those  prices  quoted  from  the  successful  proposer  in  its  sealed  price  proposal 
shall  comprise  this  section  of  the  contract. 
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PVPMISS  CONTRACT 


SECTION  V:  CITY  OF  BOSTON  STANDARD  CONTRACT 
TERMS  AND  CONDITIONS 


City  of  Boston  Standard  Contract  Terms  and  Conditions  are  comprised  of  the  terms, 
conditions  and  certifications  set  forth  on  the  following  documents: 

City  of  Boston  Standard  Contract  (Forms  CM10  and  CM11) 

Certificate  of  Authority 

Contractor  Certification 

Bid  Response  Form 

State  Tax  Return  Certificate 

Addendum  Promoting  MWBE 

Performance  Bond 

Location  of  the  Above  Referenced  Standard  Contract  Documents  in  the  RFP 

Copies  of  the  above  referenced  standard  contract  documents  are  provided  at  the  end  of  this 
section  of  the  RFP. 
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PVPMISS  CONTRACT 


SECTION  VI:  ADDITIONAL  CONTRACT  TERMS 
AND  CONDITIONS 


AGREEMENT  Dated  July  1,  2010,  between  the  CITY  OF  BOSTON,  MASSACHUSETTS, 
a  municipal  corporation,  acting  by  and  through  its  Commissioner  of  Transportation/Parking 
Clerk  (the  "City")  and 

(the  Contractor), 


having  offices  at 


WHEREAS,  the  Contractor  is  willing  to  provide  the  City  with  services  for  the  processing 
and  collection  of  parking  tickets  and  the  provision  and  operation  of  a  Parking 
Violation/Parking  Management  Information  Services  System  (PVPMISS)  described  in 
(Title  of  Contractor's  Proposal)      and  in  accordance  with  Section  IV,  (Schedule  of  Fees); 
and   


WHEREAS,  the  City  wishes  to  purchase  such  services  in  order  to  enforce  parking 
regulations  and  collection  of  parking  violation  fines  in  the  City  and  to  achieve  its  PVPMISS 
related  transportation  and  parking  management  objectives  in  a  manner  that  provides 
maximum  responsiveness  to  the  public; 

NOW,  THEREFORE,  in  consideration  of  the  mutual  covenants  herein  contained,  the 
parties  agree  as  follows: 


A.  PARTIES  TO/EXTENT  OF  AGREEMENT 

1.  Extent  of  Agreement  -  This  Agreement  consists  of  the  following: 

Section  I:  PVPMISS  RFP 

Section  II:  Contractor's  PVPMISS  Proposal 

Section  III:  Collection  of  Delinquent  (Secondary) 

Parking  Ticket  Accounts 
Section  IV:  Schedule  of  Fees 
Section  V:  City  of  Boston  Standard  Contract  Terms 

and  Conditions 
Section  VI:  Additional  Contract  Terms  and  Conditions 
Section  VII:  Signatory  Page 

2.  Jurisdiction  -  This  Agreement  shall  provide  for  the  control  and  processing  of  all 
parking  violation  tickets  and  abandoned  vehicle  violation  tickets  which  are  the 
responsibility  of  the  Parking  Clerk  of  the  City  during  the  effective  term  of  this 
Agreement. 
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3.      Subcontractors  -  For  other  subcontracting  services,  the  Contractor  may  engage  any 
other  subcontractors  of  choice  at  their  expense,  provided  however,  that  the 
Contractor  identifies  all  subcontractors  to  the  City  in  advance,  and  further 
provided  that  the  Contractor,  if  requested,  will  provide  the  City  with  a  copy  of  its 
contract  with  each  and  every  subcontractor.  Notwithstanding  the  engagement  of 
any  subcontractor,  the  Contractor  shall  bear  responsibility  under  the  terms  of  this 
Contract  for  performance  of  those  tasks  described  in  Section  I,  'Request  for 
Proposals'. 


4.      Assignment  -  This  Agreement  may  not  be  assigned  without  the  prior  written 
consent  of  each  of  the  parties  hereto. 


5.      Change  in  Authority  -  In  the  event  of  action  by  the  Commonwealth  of 

Massachusetts,  Supreme  Judicial  Court,  or  the  City  which  transfers  authority  for 
processing  of  parking  violation  citations  to  a  new  or  different  agency  of  the  City, 
this  Agreement  shall  remain  in  full  force  and  effect.  Should  the  cost  of 
performance  of  this  Agreement  by  the  Contractor  increase  or  decrease  as  a  result 
of  such  transfer  of  authority,  the  parties  will  negotiate  an  equitable  adjustment  of 
the  Contractor's  performance  or  the  cost  thereof. 


6.      Contractor  Relationship  to  the  City  -  the  Contractor's  relationship  to  the  City  in  the 
performance  of  this  Agreement  is  that  of  independent  contractor.  Personnel 
performing  services  under  this  Agreement  shall  at  all  times  be  under  the  exclusive 
direction  and  control  of  the  Contractor  or  its  subcontractors  and  shall  not  be 
deemed  to  be  employees  of  the  City. 

The  Contractor  and  its  subcontractors  shall  pay  all  wages  and  salaries  and  shall  be 
responsible  for  all  reports  and  obligations  respecting  them  relating  to  social 
security,  income  tax  withholding,  unemployment  compensation  and  similar 
matters.  Neither  the  Contractor,  its  subcontractors,  nor  any  agent  or  employees  of 
the  Contractor  shall  obtain  any  right  to  retirement  benefits  which  accrue  to 
employees  of  the  City,  and  the  Contractor  hereby  expressly  waives  any  claim  it 
might  have  to  such  rights. 
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B.  EFFECTIVENESS  OF  AGREEMENT 


1.  This  Agreement  is  effective  as  of  July  \,  2010. 

2.  The  making  and  performance  of  this  Agreement  on  behalf  of  the  City  are  subject 
to  the  availability  of  funds  sufficient  to  discharge  the  City's  obligations  under  this 
Agreement,  and  to  the  approvals  of  public  officials  as  required  by  statute, 
regulation,  or  administrative  order.  This  Agreement  shall  not  take  effect  unless 
and  until  such  funding  and  all  such  approvals  have  been  obtained.  The  Auditor  of 
the  City  shall  have  sole  authority  to  determine  and  confirm  that  such  funding  is 
available. 

3.  The  City  agrees  to  make  all  reasonable  efforts  to  obtain  funding  and  all 
necessary  approvals,  and  to  notify  the  Contractor  promptly  when  they  have 
been  obtained  or  when  it  appears  certain  that  they  will  not  be  obtained. 


C.  TERM  OF  AGREEMENT 

This  Agreement  shall  be  in  force  from  the  effective  date  as  set  forth  in  paragraph  B, 
Section  VI,  for  an  initial  term  of  twelve  (12)  months,  commencing  July  1,  2010,  and 
ending  June  30,  2011,  with  options  on  the  part  of  the  City  to  renew  for  two  (2) 
successive  twelve  (12)  month  periods  ending  on  June  30,  2013,  subject,  however,  to  an 
investigation  by  the  City  that  the  exercise  of  the  option  is  more  advantageous  than 
alternative  means  of  procuring  comparable  services  and  subject  further  to  the  availability 
of  an  appropriation  in  each  subsequent  fiscal  year,  unless  terminated  as  provided  for 
herein  or  upon  notice  by  the  City  effective  at  the  end  of  each  twelve  month  period,  such 
notice  to  be  provided  ninety  (90)  days  in  advance  of  the  end  of  the  period. 


D.  PAYMENT 

1.      Invoicing  Procedure  -  The  City  anticipates  that  sufficient  funds  shall  be  available 
to  allow  payment  on  a  per  item,  or  fee,  basis.  Payment  shall  be  made  when  goods 
are  delivered  and  services  rendered  by  the  Contractor,  and  the  goods  and  services 
are  accepted  by  the  City.  The  Contractor  shall  bill  the  City  on  a  monthly  basis  as 
provided  in  paragraph  D(2),  below,  in  arrears  for  services  rendered  using  invoices 
in  the  form  required  by  the  City.  The  City  agrees  to  review  each  invoice  and 
within  fourteen  (14)  days  after  its  receipt,  either  approve  it  and  deliver  it  to  the 
City  Auditor  for  payment,  or  return  it  to  the  Contractor  with  a  statement  of  the 
reasons  for  its  rejection.  The  Contractor  shall  provide  the  City  with  all  reasonable 
and  normal  documentation  required  by  the  City  to  approve  such  invoices;  and  by 
giving  such  approval  the  City  does  not  waive  the  right  to  subsequently  challenge 
the  validity  of  such  billings  and  to  charge  back  the  Contractor  for  excess  billings. 
The  City  further  agrees  to  exert  its  best  efforts  to  cause  the  Collector-Treasurer  to 
pay  approved  invoices  within  thirty  (30)  days  after  its  presentation  to  the  City 
Auditor. 
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2. 


Time  of  Billing  -  The  Contractor  shall  bill  the  City  for  items  processed  in 
accordance  with  the  following  provisions: 


a.  Current  tickets  shall  be  billable  at  the  time  that  they  are  added  to  the  Master 
Violations  File. 

b.  Delinquent  (secondary)  collections  shall  be  billable  at  the  time  the  backlog 
payments  are  added  to  the  Master  Violations  File. 

c.  Monthly  Maintenance  /  Operation  fee  shall  be  billable  monthly  subject  to  the 
approval  of  the  City. 


3.      Bank  Account  -  The  City  shall  establish  an  account  at  the  bank,  or  such  successor 
bank,  providing  banking  services  performed  under  this  Agreement. 


4.      Rate  of  Compensation  -  For  delivery  of  the  products  and  the  performance  of  the 
processing  services  described  in  the  Section  I,  Request  For  Proposals  (Scope  of 
Services),  the  City  will  pay  the  Contractor  the  rates  set  forth  in  Section  IV, 
Schedule  of  Fees,  and  Section  III,  Collection  of  Delinquent  (Secondary) 
Parking  Ticket  Accounts,  respectively,  for  each  ticket  processed  by  the 
Contractor  and  for  each  backlog  parking  ticket  collected  as  a  result  of  the 
Contractor's  secondary  collection  activity. 


5.      Renewal  Rates  -  In  the  event  that  this  Agreement  is  extended  beyond  its  initial 

twelve  (12)  month  period,  or  beyond  any  following  twelve  (12)  month  periods,  the 
fees  for  services  performed  hereunder,  shall  be  adjusted  on  the  basis  of  the  lesser 
of  either  an  increase  in  the  cost  of  living  which  occurred  during  the  then  expiring 
period  of  this  Agreement  or  five  percent  (5%).  Such  cost  of  living  increase  shall 
be  a  percentage  equal  to  the  percentage  increase  in  the  Consumer  Price  Index  for 
all  Urban  Consumers  for  the  Boston  Metropolitan  Area  for  the  month  of  March 
immediately  preceding  the  renewal  date  as  compared  to  the  Index  for  the  same 
month  in  the  prior  year,  but  such  increase  shall  in  no  event  exceed  five  percent 
(5%). 


6.  Postage  Costs  -  the  City  shall  arrange  for  prepaid  postage  to  be  used  for  the 
mailing  of  all  notices  and  correspondence  to  violators  as  specified  as  a  City 
responsibility  under  this  Agreement. 


7.      Release  of  Payment  Obligations  -  the  parties  agree  that  payment  in  full  by  the  City 
to  the  Contractor  of  services  described  on  invoices  shall  relieve  the  City  of  its 
payment  obligations  to  the  Contractor  with  respect  to  the  services  billed  and  paid. 
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E.  TERMINATION 


1.      Subject  to  the  provisions  of  paragraph  (F),  Section  VI,  entitled  "Force  Majeure",  if 
the  Contractor  fails  to  fulfill  in  a  timely  and  satisfactory  manner  its  obligations 
under  this  Agreement  in  accordance  with  Section  I,  Request  For  Proposals,  as 
determined  by  the  City;  or  if  the  Contractor  shall  materially  violate  any  of  the 
covenants,  conditions,  or  stipulations  of  this  Agreement,  which  failure  or  violation 
shall  continue  unremedied  for  fourteen  (14)  days  after  written  notice  of  said  failure 
or  violation  is  received  by  the  Contractor,  then  the  City  shall  thereupon  have  the 
right  to  terminate  this  Agreement  with  the  Contractor  by  giving  written  notice  to 
the  Contractor  of  such  termination  and  specifying  the  effective  date  thereof,  such 
date  to  be  not  less  than  thirty  (30)  days  following  the  date  of  the  notice.  Subject 
once  again  to  the  provisions  of  paragraph  F,  of  Section  VI,  if  a  defect  in 
performance  is  such  that  it  cannot  reasonably  be  cured  or  corrected  within  the  said 
fourteen  (14)  day  period,  the  City  shall  have  the  right  to  terminate  the  Agreement 
unless  the  parties  can  agree  within  the  said  fourteen  (14)  day  period  to  a  plan  and 
timetable  for  correcting  the  defect,  and  if  a  plan  and  timetable  is  agreed  upon,  the 
Contractor  shall  not  be  considered  in  default  under  this  Agreement  so  long  as  it 
cures  the  defect  in  accordance  with  said  plan  and  timetable.  The  City  shall, 
however,  have  a  right  to  terminate  the  Agreement  if  such  defect  is  not  remedied  in 
accordance  with  said  plan  and  timetable,  by  giving  written  notice  to  the  Contractor 
of  such  termination  and  specifying  the  effective  date  thereof,  such  date  to  be  not 
less  than  thirty  (30)  days  following  the  date  of  the  notice.  The  parties  must 
negotiate  in  good  faith  the  plan  referred  to  in  the  second  sentence  of  this 
paragraph. 


2.      Subject  to  the  provisions  of  paragraph  F,  Section  VI,  entitled  "Force  Majeure",  if 
the  City  shall  fail  to  fulfill  in  a  timely  and  satisfactory  manner  its  obligations  under 
this  Agreement;  or  if  the  City  shall  violate  any  of  the  covenants,  conditions,  and 
stipulations  of  this  Agreement,  which  failure  or  violation  shall  continue 
unremedied  for  fourteen  (14)  days  after  written  notice  of  said  failure  or  violation  is 
received  by  the  City;  or  alternately,  after  such  notice  beyond  a  reasonable  or 
mutually  agreed  upon  period  of  time  to  be  outlined  in  a  plan  to  correct  the  default; 
then  the  Contractor  shall  thereupon  have  the  right  to  terminate  this  Agreement  by 
giving  written  notice  to  the  City  of  such  termination  and  specifying  the  effective 
date  thereof,  such  date  to  be  not  less  than  thirty  (30)  days  following  the  date  of  the 
notice. 
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3.      Subject  to  the  provisions  of  paragraph  E(7),  Section  VI,  in  the  event  of 

termination,  the  Contractor  remains  bound  to  fulfill  each  and  every  obligation  and 
responsiblility  assigned  to  it  in  Section  I,  up  to  and  including  the  termination  date, 
described  above.  After  the  termination  date,  the  Contractor  shall  process  all 
documents  and  checks  in  its  possession  and/or  under  their  control.  As  soon  as 
possible  after  the  termination  date,  the  Contractor  shall  deliver  to  the  City,  without 
limitation,  all  finished  and  unprocessable  work,  including  all  violation  documents, 
bad  checks,  microfiche,  computer  tapes,  and  all  other  products  described  in  the 
Scope  of  Services.  The  Contractor  shall  certify,  under  the  pains  and  penalties  of 
perjury,  that  all  such  work  has  been  returned  to  the  City.  In  addition,  the 
Contractor  shall  provide,  without  limitation,  any  and  all  program  specifications, 
and  any  other  material,  including  that  prepared  by  the  Contractor  for  utilization  of 
the  system,  except  material  which  is  proprietary  in  nature,  as  may  be  necessary  for 
the  City  to  utilize  the  products  described  in  Scope  of  Services,  or  to  establish 
alternative  processing  of  the  documents  and  checks. 


4.      Notwithstanding  the  above,  in  the  event  of  termination,  the  Contractor  shall  not  be 
relieved  of  liability  to  the  City  by  virtue  of  any  breach  of  this  Agreement  by  the 
Contractor. 


5.      (This  paragraph  intentionally  omitted.) 


6.      Article  8.4  of  the  City  of  Boston  Standard  Contract,  General  Conditions,  shall  have 
no  force  or  effect.  Termination  of  the  Contract  for  the  convenience  of  the  City 
shall  be  as  follows.  The  City  may,  upon  delivery  of  a  notice  by  certified  mail  to 
the  Contractor,  terminate  this  contract  without  cause  on  a  date  of  its  choice,  but  in 
no  event  sooner  than  ninety  (90)  days  after  the  receipt  of  said  notice. 

If  the  contract  is  terminated  under  this  paragraph,  the  City  shall  pay  to  the 
Contractor,  as  a  cancellation  fee,  an  amount  which  is  fair  and  equitable  under  the 
circumstances,  giving  due  consideration  to  the  Contractor's  unavoidable  costs  and 
other  relevant  factors.  The  cancellation  fee  shall  be  in  addition  to  any  amounts 
payable  under  paragraph  E(7),  Section  VI.  The  parties  shall  negotiate  in  good 
faith  with  respect  to  the  amount  payable  hereunder  in  the  event  of,  or  prior  to,  an 
early  cancellation.  The  Commissioner  of  Transportation/Parking  Clerk  of  the  City 
may,  if  he/she  so  elects,  agree  to  a  per  diem  rate  to  be  payable  upon  early 
cancellation  by  the  City. 


7.      If  the  City  elects  to  not  renew  this  Agreement  as  provided  in  paragraph  C, 

Section  VI,  or  to  terminate  this  Agreement  as  provided  in  paragraphs  E(l),  or 
E(6),  Section  VI,  it  shall  select  one  of  the  following  options  for  the  winding 
down  of  operations  and  shall  notify  the  Contractor  of  the  option  selected  when 
the  notice  of  non-renewal  or  termination  is  given. 
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OPTION  A 


The  Contractor  shall  cease  performing  all  services  on  the  date  of  termination.  The 
Contractor  will,  however,  be  required  to  update  the  Master  Violations  File  for 
Massachusetts  registrations  and  this  update  shall  be  completed  within  ten  (10)  days 
after  the  date  of  termination.  The  fee  payable  for  tickets  issued  within  thirty  (30) 
days  before  the  termination  date  (in  the  case  of  termination  for  cause),  ninety  (90) 
days  (in  the  case  of  non-renewal)  or  ninety  (90)  days  (in  the  case  of  termination 
without  cause)  shall  be  the  comprehensive  per  ticket  processing  price  of  the 
current  or  recently  expired  contract  period. 


OPTION  B 

The  Contractor  shall  continue  to  perform  all  or  a  portion  of  the  services  required 
under  Section  I  and  II  with  respect  to  tickets  issued  up  to  the  date  of  termination 
for  a  maximum  of  one  hundred  twenty  (120)  days  after  that  date.  The  City  shall 
pay  the  amounts  specified  in  Section  III,  Collection  of  Delinquent  Parking  Tickets 
Accounts,  and  in  Section  IV,  Schedule  of  Fees,  subject  to  the  conditions  therein. 
The  City  shall  also  pay  one-tenth  (1/10)  of  the  basic  per  ticket  fee  for  each  ticket 
noticed  by  the  Contractor  within  sixty  (60)  days  after  the  date  of  termination. 


F.  FORCE  MAJEURE  AND  IMPOSSIBILITY  OF  PERFORMANCE 

None  of  the  parties  will  be  liable  to  the  other  or  be  deemed  to  be  in  breach  under  this 
Agreement  for  any  failure  or  delay  in  performance  due  to  causes  beyond  its  reasonable 
control,  including  without  limitation,  an  Act  of  God,  war,  strikes,  civil  disobedience, 
actions  or  omissions  of  third  parties  (other  than  subcontractors),  extraordinary  weather 
conditions,  or  failure  of  the  other  party  to  act  in  a  timely  manner. 

Date  or  time  of  performance  will  be  extended  automatically  to  the  extent  of  such  delays, 
provided  that  the  party  whose  performance  is  affected  notifies  the  other  in  writing  of  the 
existence  and  nature  of  such  delay  within  fourteen  (14)  days  of  its  occurrence. 

It  is  agreed,  however,  that  since  the  performance  of  this  Agreement  is  vitally  important, 
not  only  to  the  provision  of  essential  parking  and  transportation  management  and 
adjudication  programs  but  also  to  the  functioning  of  the  City,  continued  failure  to 
perform  for  periods  aggregating  twenty  (20)  or  more  days  in  any  ninety  day  period 
except  for  failure  of  the  City  to  act  in  a  timely  fashion,  shall  be  deemed  to  render 
performance  impossible,  and  the  City  shall  thereafter  have  the  right  to  terminate  this 
Agreement  in  accordance  with  the  provisions  of  the  Article  entitled  "Termination". 
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G.  OWNERSHIP  OF  INFORMATION 


1.  All  information  acquired  by  the  Contractor  from  the  City  or  from  others  at  the 
direct  or  indirect  expense  of  the  City  in  the  performance  of  this  Agreement,  shall 
be  and  remain  the  property  of  the  City.  This  includes  all  data  contained  in 
databases  including  the  name  and  address  records  of  out-of-state  registrants. 

2.  The  Contractor  agrees  that  it  will  use  this  information  only  as  required  in  the 
performance  of  this  Agreement,  and  will  not  before,  during,  or  after  the 
completion  of  this  Agreement  otherwise  use  said  information,  nor  copy  or 
reproduce  the  same  in  any  form,  except  pursuant  to  the  sole  written  instructions  of 
the  City.  The  Contractor  further  agrees  to  return  said  information  to  the  City 
promptly  at  the  request  of  the  City  on  tape  media  or  in  whatever  form  it  is 
maintained  by  the  Contractor.  The  Contractor  will  provide  the  City  with  complete 
documentation  as  to  file  contents  and  record  layouts  within  thirty  (30)  days 
following  the  request  of  the  City. 


H.  CONFIDENTIALITY  OF  INFORMATION  -  CONFIDENTIALITY 

1.      The  Contractor  recognizes  that  in  the  performance  of  this  Agreement,  it  will 

become  holder  of  and  have  access  to  confidential  information.  In  the  performance 
of  this  Agreement,  the  Contractor  agrees  that  it  will  comply  with  the  laws  and 
regulations  of  the  Commonwealth  of  Massachusetts,  ordinances  and  regulations  of 
the  City,  and  any  applicable  federal  laws  and  regulations,  including  amendments 
thereto,  relating  to  confidentiality. 

At  all  times,  the  Contractor  will  recognize  the  City's  sole  and  exclusive  ownership 
of  this  information  and  the  sole  and  exclusive  right  and  jurisdiction  of  the  City  to 
control  the  use  of  this  information.  THE  CONTRACTOR  AGREES  THAT 
NEITHER  IT.  NOR  ITS  EMPLOYEES.  SUBCONTRACTORS.  OR  AGENTS- 
WILL  DISCLOSE  ANY  INFORMATION  CONTAINED  IN  OR  SET  FORTH 
BY  ANY  RECORD  OR  DOCUMENT  RECEIVED  BY  THE  CONTRACTOR 
ON  BEHALF  OF  THE  CITY  TO  ANY  PERSON  EXCEPT  THE  AUTHORIZED 
RECIPIENT  OF  THE  CITY.  THE  CITY  SHALL  AUTHORIZE.  IN  WRITING. 
AN  EMPLOYEE  OR  EMPLOYEES  TO  RECEIVE  THIS  INFORMATION. 

The  Contractor  further  agrees  that  it  shall  make  no  use  of  any  of  the  described 
information,  for  either  internal  or  external  purposes,  other  than  such  as  is  directly 
related  to  the  performance  of  this  Agreement. 

The  Contractor  further  agrees  that  upon  notification  to  the  Contractor  that  this 
information  has  been  improperly  used  or  removed  in  any  way  from  the  possession 
or  control  of  the  Contractor  by  anyone  except  the  City  or  its  authorized 
representative,  the  Contractor  shall  immediately  notify  the  City  orally  and  in 
writing,  and  shall  join  with  the  City  at  its  request  in  taking  such  steps  as  the  City 
may  deem  advisable  to  enjoin  the  misuse  and  regain  possession  of  said  data,  or 
steps  otherwise  necessary  for  the  protection  of  the  City's  rights  and  the 
confidentiality  of  the  information. 
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2.  In  addition  to  steps  the  Contractor  may  take  to  ensure  the  confidentiality  of  this 
information,  the  Contractor  shall  comply  with  reasonable  security  measures 
submitted  by  the  City  including  those  measures  set  forth  in  Paragraph  I.,  Section 
VI,  and  Section  I,  Request  For  Proposals.  Failure  of  the  City  to  provide  a  partial 
or  complete  security  plan  shall  not  be  construed  as  relieving  the  Contractor  of 
responsibility  described  in  Section  VI. 

3.  The  Contractor  agrees  to  return  any  and  all  data  furnished  pursuant  to  this 
Agreement  promptly  at  the  request  of  the  City. 

4.  The  Contractor  shall  comply  with  the  provisions  of  Massachusetts  General  Laws 
(MGL)  c.  6,  ss.  167-178,  the  Criminal  Offender  Record  Information  System 
(CORI),  if  applicable.  The  Contractor  understands  and  agrees  that  any  person 
who  willfully  requests,  obtains  or  seeks  to  obtain  criminal  offender  record 
information  under  false  pretenses,  or  who  willfully  communicates  or  seeks  to 
communicate  criminal  record  information  to  any  agency  or  person  except  in 
accordance  with  the  M.G.L.  c.  6,  ss.  168-175,  inclusive,  shall  be  punishable  in 
accordance  with  the  provisions  of  MGL  c.  6,  Section  178. 

5.  If  performance  of  the  tasks  outlined  in  the  Scope  of  Services  requires  that  the 
Contractor  gain  CORI  (Criminal  Offender  Record  Information)  clearance  from  the 
Criminal  History  Systems  Board  of  the  Commonwealth  of  Massachusetts,  then 
award  of  the  contract  will  be  contingent  upon  the  approval  of  a  CORI  application 
by  said  Board. 

6.  All  computer  software,  programs  and  systems,  and  technical  proprietary 
specifications  and  procedures,  as  they  relate  to  the  services  to  be  performed  under 
this  Agreement  are  proprietary  and  shall  remain  exclusively  the  sole  property  of 
the  Contractor  and  the  City  shall  acquire  no  right  or  title  to  such  items.  The  City 
shall  not  provide  or  otherwise  make  available  said  software,  systems,  programs, 
specifications  or  procedures,  in  any  form,  to  any  person,  except  as  required  by  law, 
and  as  otherwise  provided  in  this  Article.  In  order  to  enable  the  Contractor  to 
carry  out  its  work  hereunder,  to  some  extent  the  Contractor  will  have  to  impart 
information  which  is  the  subject  of  this  paragraph. 

To  the  extent  that  such  confidential  material  is  imparted  to  the  City's  employees, 
the  City  agrees  that  it  will  retain  all  information  submitted  by  the  Contractor  to  the 
City  in  strictest  confidence  and  will  neither  use  nor  disclose  it  to  other  than  City 
employees  who  have  a  need  to  know  in  connection  with  this  contract  without  the 
explicit  permission  of  the  Contractor.  The  City  recognizes  that  irreparable  harm 
may  be  occasioned  to  the  Contractor  by  disclosure  of  information  relating  to  its 
business  and  that  the  Contractor  may  accordingly  enjoin  such  disclosure. 
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I.  SECURITY 


The  Contractor  will  provide  and  operate  a  complete  security  system  which  will  protect 
both  the  physical  documents  and  the  information  contained  therein  from  time  of  the 
Contractor's  receipt  until  delivery  to  the  City. 


Security  shall  include  without  limitation:  fire  protection,  protection  against  smoke  and 
water  damage,  alarm  systems,  locked  files,  guards,  or  other  devices  reasonably  expected 
to  prevent  loss  or  unauthorized  removal  of  documents  and/or  manually  held  data; 
passwords,  access  logs,  badges,  or  other  methods  reasonably  expected  to  prevent  loss  or 
unauthorized  access  to  electronically  or  mechanically  held  data;  limited  terminal  access, 
use  of  terminal  passwords  which  will  be  changed  on  a  regular  basis,  limited  access  to 
input  documents  and  output  documents,  and  design  provisions  to  limit  use  of  client  or 
applicant  name. 


The  Contractor  shall  provide  the  City  with  a  description  of  its  security  system  and 
procedures  used  to  provide  and  operate  the  system.  The  Contractor  must  protect  the 
integrity  of  the  City's  information  as  well  as  limit  access  to  that  information. 


In  addition  to  steps  the  Contractor  may  take  to  secure  the  system,  the  Contractor  shall 
comply  with  reasonable  security  measures  submitted  by  the  City.  Failure  of  the  City  to 
provide  a  partial  or  complete  security  plan  shall  not  be  construed  as  relieving  the 
Contractor  of  responsibility  described  in  this  section. 


J.  PERFORMANCE  REVIEW 

The  representatives  of  the  parties  or  their  designees,  from  time  to  time,  will  meet  as 
often  as  requested  by  either  of  them,  to  review  the  performance  of  the  parties  under  this 
Agreement.  The  City,  from  time  to  time,  or  at  it's  sole  discretion,  during  the  regular 
operations  phase,  may  request  that  a  formal  status  report  be  submitted.  The  Contractor 
will  comply  with  all  such  requests.  In  the  event  of  any  disagreement  between  the 
parties,  with  respect  to  either  the  interpretation  of  any  provision  of  this  Agreement  or  the 
performance  of  a  party,  each  party  will  appoint  a  representative  to  meet  for  the  purpose 
of  endeavoring  to  resolve  that  disagreement.  They  will  meet  as  often  as  the  parties 
reasonably  deem  necessary  in  order  to  gather  and  furnish  for  each  other  all  information 
with  respect  to  the  matter  in  issue  that  the  respective  parties  believe  to  be  appropriate, 
and  they  will  discuss  the  problem  in  an  effort  to  resolve  that  disagreement. 
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K.  WITHHOLDING  OF  FEES 


The  City  shall  have  the  right  to  withhold  the  payment  to  the  Contractor  of  all  processing 
and  collection  fees  due  and  payable  pursuant  to  this  Agreement  for  a  continued  failure 
by  the  Contractor  to  perform  any  of  its  material  obligations  as  described  in  this 
Agreement.  Such  right  to  withhold  shall  continue  until  the  Contractor  remedies  such 
failure  to  perform  provided,  however,  that  such  failure  must  have  been  identified  in 
writing  and  delivered  by  certified  mail  to  the  Contractor  prior  to  such  withholding.  If, 
however,  the  Contractor's  non-performance  is  related  only  to  a  specific  group  of  tickets, 
and  it  can  provide  sufficient  documentation  to  substantiate  non-performance  being 
specifically  limited  to  these  tickets,  the  City's  right  to  withhold  payment  shall  be  limited 
to  the  fees  paid  or  payable  relative  to  such  tickets  until  the  defect  is  remedied. 


L.  LIQUIDATED  DAMAGES 

1.  If  either  the  performance  of  or  the  failure  to  perform  the  terms  and  conditions  set 
forth  in  this  contract  result  in  the  loss  of  data  and  the  corresponding  ability  to 
collect  associated  fines,  liquidated  damages  shall  be  due  the  City  in  the  amounts 
provided  for  in  the  following  sentence.  Such  liquidated  damages  shall  be  the  sum 
of  the  face  value  of  any  and  all  items  issued  by  the  City  and  received  by  the 
Contractor  for  which  the  loss  of  data  and  the  corresponding  ability  to  collect  the 
associated  fine  has  occurred.  The  phrase  face  value  shall  mean  the  amount  of  the 
violation  fine  and  applicable  surcharges  or  assessed  penalties. 

2.  The  damages  specified  in  paragraph  L(l),  Section  VI,  shall  be  in  lieu  of  any  other 
damages  arising  out  of  the  same  acts  or  omissions. 

3.  Payment  of  the  liquidated  damages  to  the  City  shall  be  by  way  of  a  deduction  from 
amounts  owed  the  Contractor  hereunder.  Any  such  deductions  shall  be  specified 
in  writing  by  the  City. 
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M.  PERFORMANCE  BOND 


Simultaneously  with  the  execution  of  this  Agreement,  the  Contractor  shall  provide,  at  its 
own  expense,  a  performance  bond  in  the  amount  of  one  million  dollars  ($1,000,000)  as 
security  to  guarantee  the  faithful  performance  by  the  Contractor  of  its  obligations  under 
this  Agreement.  The  performance  bond  shall  be  of  a  surety  company  authorized  to  do 
business  in  Massachusetts  and  satisfactory  in  form  to  the  City.  The  performance  bond 
shall  be  in  effect  for  the  full  term  of  this  Agreement.  In  the  event  that  this  Agreement  is 
extended  beyond  its  initial  twelve  (12)  month  period,  or  beyond  any  following  twelve 
(12)  month  period(s),the  Contractor  shall  continue  to  provide,  at  its  own  expense,  said 
performance  bond  in  force  for  each  of  the  extended  twelve  (12)  month  periods  as 
security  to  likewise  guarantee  the  faithful  performance  of  any  such  renewal(s)  of  this 
Agreement. 


N.  INSPECTION.  MONITORING.  AND  EVALUATION 

To  assure  compliance  with  this  Agreement  the  City  shall  have  the  right  to  enter  onto  the 
Contractor's  and  its  subcontractors'  premises  during  normal  business  hours  to  inspect, 
monitor,  or  otherwise  evaluate  the  work  performed  or  being  performed  therein.  The  City 
shall  be  permitted  access  to  all  files  used  in  the  processing  of  its  information  at  all 
reasonable  times,  which  access  shall  not  be  denied  by  the  Contractor  or  its 
subcontractors  for  any  reason  whatsoever. 

The  Contractor  shall  assure  that  the  City,  or  its  duly  authorized  representatives,  shall 
have  access  during  normal  business  hours  to  any  books,  documents,  records,  and  papers 
retained  by  the  Contractor  and  its  subcontractors  which  the  City  reasonably  determines 
are  directly  pertinent  to  this  Agreement  for  the  purpose  of  making  audit  or  examination, 
and  of  taking  excerpts  and  transcripts. 


O.  CONFLICT  OF  INTEREST 

1.  The  Contractor  agrees  to  the  extent  that  such  law  is  applicable  to  the  duties  it  is  to 
perform  hereunder,  it  will  comply  with  the  provisions  of  Chapter  268A  of 
Massachusetts  General  Laws  concerning  conflict  of  interest.  The  Contractor 
covenants  that  it  presently  has  no  interest  and  shall  not  acquire  any  interest,  direct 
or  indirect,  which  would  conflict  in  any  manner  or  degree  with  the  performance  of 
services  required  to  be  performed  under  this  Agreement. 

2.  No  employee  of  the  City  and  no  public  official  who  exercises  any  function  or 
responsibilities  in  the  review  or  approval  of  the  undertaking  or  carrying  out  of 
this  Agreement  shall:  (a)  participate  in  any  decision  relating  to  this  Agreement 
which  affects  his  personal  interest  or  the  interest  of  any  corporation,  partnership, 
or  association  which  he  is,  directly  or  indirectly,  interested;  or  (b)  have  any 
financial  interest,  direct  or  indirect,  in  this  Agreement  or  the  proceeds  thereof. 
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P.  ANTI-BOYCOTT  COVENANT 


The  Contractor  warrants,  represents,  and  agrees  that  during  the  time  this  Agreement  is  in 
effect  neither  it  nor  any  affiliated  company,  as  hereafter  defined,  will  participate  in  or 
cooperate  with  an  international  boycott  as  defined  in  Section  999(b),  (3)  and  (4)  of  the 
Internal  Revenue  Code  of  1954,  as  amended,  or  engage  in  conduct  declared  to  be 
unlawful  by  Section  2  of  Chapter  151E  of  the  Massachusetts  General  Laws.  If  there  shall 
be  a  breach  in  the  warranty,  representation,  and  agreements  contained  in  this  paragraph, 
then  without  limiting  such  other  rights  as  it  may  have,  the  City  shall  be  entitled  to 
terminate  this  Agreement.  As  used  herein,  an  affiliated  company  shall  be  any  business 
entity  or  entities  directly  or  indirectly  owning  at  least  51%  of  the  ownership  interests  of 
the  Contractor  or  which  directly  or  indirectly  owns  at  least  50  %  of  the  ownership 
interest  of  the  Contractor. 


O.  NONDISCRIMINATION  IN  EMPLOYMENT  AND  AFFIRMATIVE  ACTION 

1.      The  Contractor  shall  not  discriminate  against  any  qualified  employee  or  applicant 
for  employment  because  of  race,  color,  national  origin,  ancestry,  age,  sex,  religion, 
or  physical  or  mental  handicap.  The  Contractor  agrees  to  comply  with  all 
applicable  Federal  and  State  statutes,  rules,  and  regulations  prohibiting 
discrimination  in  employment,  including:  Title  VII  of  the  Civil  Rights  Act  of  1964: 
the  Age  Discrimination  in  Employment  Act  of  1967;  Section  504  of  the 
Rehabilitation  Act  of  1973;  Massachusetts  General  Laws,  Chapter  151B,  Section 
4(1);  and  all  relevant  administrative  orders  and  executive  orders. 


2.      If  a  complaint  or  claim  alleging  violation  by  the  Contractor  of  such  statutes,  rules, 
or  regulations  is  presented  to  the  Massachusetts  Commission  Against 
Discrimination  (MCAD),  the  Contractor  agrees  to  provide  all  information  and 
reports  required  by  MCAD,  to  permit  access  to  its  facilities,  and  to  permit  access 
to  such  of  its  books,  records,  accounts,  and  other  sources  of  information  as  may  be 
determined  by  the  City,  the  MCAD,  or  both,  to  be  pertinent  to  ascertain 
compliance  with  MCAD  orders  or  instructions.  Where  the  information  required  is 
in  the  sole  possession  of  another  who  fails  or  refuses  to  furnish  this  information, 
the  Contractor  shall  so  certify  to  the  Department  or  the  MCAD  as  appropriate  and 
shall  describe  the  efforts  it  has  made  to  obtain  the  information. 


3.      In  the  event  of  the  Contractor's  noncompliance  with  the  provisions  of  this  section 
the  City  shall  impose  such  sanctions  as  it  deems  appropriate,  including,  but  not 
limited  to: 

a.  Withholding  of  payments  due  the  Contractor  under  this  Agreement  until  the 
Contractor  complies;  and/or 

b.  Termination  or  suspension  of  this  Agreement. 
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R.  ASSIGNMENT 


The  Contractor  shall  not  assign  or  in  any  way  transfer  any  interest  in  this  Agreement 
without  the  prior  written  consent  of  the  City  provided,  however,  that  claims  for  money 
due  or  to  become  due  to  the  Contractor  from  the  City  hereunder  may  be  assigned  to  a 
bank,  trust  company,  or  other  financial  institution  without  consent  so  long  as  notice  of 
any  such  assignment  is  furnished  promptly  to  the  City.  Any  such  assignment  shall  be 
expressly  made  subject  to  all  defenses,  set-offs,  or  counterclaims  which  would  have  been 
available  to  the  City  against  the  Contractor  in  the  absence  of  such  assignment. 


S.  GOVERNING  LAW 

This  Agreement  shall  be  governed  by  and  construed  in  accordance  with  the  laws  of  the 
Commonwealth  of  Massachusetts. 


T.  NOTICES  TO  PARTIES 

Any  notice  required  under  this  Agreement  to  be  given  to  any  party  may  be  given  by 
depositing  in  the  United  States  mail,  postage  prepaid,  first-class,  a  notice  addressed  to 
the  following.  Any  notice  to  be  given  relative  to  this  Agreement  shall  be  given  to  all 
parties. 

To  the  City: 

Boston  Transportation  Department 
City  Hall,  Room  721 
Boston,  Massachusetts  02201 

ATTN:  Commissioner  of  Transportation/Parking  Clerk 

Boston  Transportation  Department/Office  of  the  Parking  Clerk 
City  Hall,  Room  224 
Boston,  Massachusetts  02201 
ATTN:  Assistant  Parking  Clerk 

To  the  Contractor: 


ATTN: 
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U.  DESIGNATED  REPRESENTATIVE 


The  City  and  the  Contractor  shall  designate,  in  writing,  a  single  individual  as  their 
representatives.  The  designated  representatives  shall  represent  the  parties  in  all  matters 
pertaining  to  this  contract  and  shall  have  sole  authority  to  commit  the  parties  in  matters 
relative  to  this  contract. 


V.  RELEASE  OF  CITY  ON  FINAL  PAYMENT 

Acceptance  by  the  Contractor  of  payment  from  the  City  for  final  services  under  this 
Agreement  shall  be  deemed  to  release  the  City  from  all  claims  and  liabilities,  except 
those  of  which  the  Contractor  notifies  the  City  in  writing  within  six  (6)  months  after 
such  payment. 


W.  LETTER  OF  AWARD 

The  letter  to  the  Mayor  of  Boston  from  the  Commissioner  of  Transportation  concerning 
the  award  of  this  contract  to  the  Contractor  and  approved  by  the  Mayor  is  incorporated 
herein  by  reference  as  is,  set  forth  in  its  entirety. 


X.  LIABILITY  AND  INSURANCE 

The  Contractor  agrees,  during  the  term  of  this  Agreement,  to  maintain  at  the  Contractor's 
expense,  all  insurance  required  by  law  for  their  employees,  including  disability, 
workmen's  compensation,  and  unemployment  compensation  and  to  provide  the  City  with 
certification  of  same  upon  request.  The  Contractor  shall  assure  and  require  that  all 
subcontractors  maintain  the  same  types  of  insurance  for  their  employees. 

The  Contractor  shall  defend  and  hold  the  City  harmless  from  any  and  all  legal  liability 
which  may  be  established  on  behalf  of  any  person  or  persons  or  corporation, 
whomsoever  for,  or  growing  out  of  any  infringement  of  letter  patent  or  copyright  of  the 
United  States,  in  respect  to  the  normal  use  of  the  proposed  and  installed  PVPMISS. 

The  Contractor  shall  take  out  and  maintain  during  the  life  of  the  contract  the  following 
insurance  by  a  responsible  insurance  company  licensed  and  authorized  to  do  business  in 
Massachusetts: 

1)     Workmen's  Compensation  insurance  in  an  amount  as  may  be  reasonably  necessary 
to  protect  the  Contractor  from  claims  under  Chapter  152  of  the  General  Laws  (the 
Workmen's  Compensation  Statute); 
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2)     Public  liability  and  property  damage  insurance  as  shall  name  the  City  of  Boston  as 
an  additional  insured  and  protect  the  Contractor  and  any  sub-contractor  performing 
work  covered  by  the  contract  from  claims  for  personal  injury,  including  wrongful 
death,  as  well  as  from  claims  for  property  damage,  which  may  arise  from 
operations  under  the  contract,  whether  such  operations  be  by  the  Contractor  or  by 
any  subcontractor  or  by  anyone  directly  or  indirectly  employed  by  either  of  them 
at,  and/or  away  from,  the  Contractor's  place  of  business  and  the  amounts  of 
insurance  shall  be  as  follows: 

a)  Public  liability  insurance  shall  be  in  an  amount  not  less  than  one  million 
dollars  ($1,000,000)  for  injuries  including  wrongful  death,  to  any  person,  and, 
subject  to  the  same  limit  for  each  person,  in  an  amount  not  less  than  two 
million  dollars  ($2,000,000)  on  account  of  one  accident.  Property  damage 
insurance  shall  be  in  an  amount  not  less  than  five  hundred  thousand  dollars 
($500,000)  for  damages  on  account  of  any  one  accident  and  an  amount  not 
less  than  one  million  dollars  ($1,000,000)  for  damages  on  account  of  all 
accidents. 

Simultaneously  with  execution  of  the  contract  the  Contractor  shall  provide  the  City  with 
policies,  binders  or  certificates  evidencing  that  the  above  insurance  is  in  full  force  and 
effect.  In  the  event  that  the  Contractor's  insurance  policy  terminates  prior  to  the  end  of  the 
contract  term,  the  Contractor  must  deliver  to  the  Parking  Clerk  evidence  of  renewal  of  all 
required  coverage. 


Y.  REFUSAL  OF  INDIVIDUAL 

The  City  reserves  the  right  to  refuse  any  individual(s)  in  the  Contractor's  employ 
(including  subcontractors)  if: 

i.  the  City  is  not  satisfied  with  their  performance  as  it  relates  to  this  Agreement;  or 

ii.  personality  conflicts  with  City  personnel  hinder  the  effectiveness  of  this 
Agreement. 

In  the  event  of  any  such  refusal,  the  Contractor's  Project  Manager  assigned  to  this 
contract  shall  immediately  notify  the  City  of  the  reassignment  (to  work  not  related  to  this 
Agreement),  resignation  or  discharge  of  any  affected  Contractor  personnel  assigned  to 
this  Contract,  and  such  personnel  shall  be  forthwith  relieved  of  any  further  work  under 
this  Contract. 

Further,  unless  otherwise  notified,  it  shall  be  assumed  that  a  replacement  is  required  for 
a  Contractor  employee  (including  subcontractors)  who  has  been  refused  from  conducting 
work  under  this  Contract  and  the  Contractor  shall  expeditiously  hire  replacements.  In  no 
event  shall  said  hiring  exceed  sixty  (60)  calendar  days  from  the  date  of  refusal  by  the 
City. 

The  City's  refusal  of  an  individual  shall  in  no  way  relieve  the  Contractor  of  any  of  its 
responsibilities  set  forth  in  this  Contract. 
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Z.  ENTIRE  AGREEMENT 

Sections  I  through  VII,  inclusive,  of  this  Contract  is  the  entire  agreement  between  the 
parties  with  respect  to  its  subject  matter,  and  cannot  be  modified  or  terminated  orally. 
No  modification  or  any  claim  of  waiver  of  any  of  the  provisions  shall  be  effective  unless 
in  writing  and  signed  by  both  parties. 
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PVPMISS  CONTRACT 


SECTION  VII:  SIGNATORY  PAGE 


WHEREFORE,  the  parties  hereto  have  entered  into  this  Agreement  as  of  the  day  and  year 
first  written  above. 


(CONTRACTOR  NAME). 


BY: 


TITLE: 


CITY  OF  BOSTON 


BY:   

COMMISSIONER  OF  TRANSPORTATION/ 
PARKING  CLERK 


APPROVED  AS  TO  FORM 
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PVPMISS  CONTRACT 


COPIES  OF  THE  CITY  OF  BOSTON  STANDARD 
CONTRACT  DOCUMENTS 


The  list  below  comprises  the  City's  Standard  Contract  Documents.  Copies  of  these 
documents  appear  on  the  following  pages. 

City  of  Boston  Standard  Contract  (Forms  CM10  and  CM11) 

Certificate  of  Authority 

Contractor  Certification 

Bid  Response  Form 

State  Tax  Return  Certificate 

Addendum  Promoting  MWBE 

Performance  Bond 

Living  Wage  Ordinance 


NOTE:  CONTRACT  FORMS  ARE  ONE  SIDED. 
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INSERT  CONTRACT  CM10/CM11 
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INSERT  STANDARD  CONTRACT 
GENERAL  CONDITIONS 
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CERTIFICATE  OF  AUTHORITY 

(For  Corporations  Only) 


(Form  CM  6) 


(Current  Date) 

At  a  meeting  of  the  Directors  of  the  

(Name  of  Corporation) 
duly  called  and  held  at  

on  the  day  of  ,  ,  at 

which  a  quorum  was  present  and  acting,  it  was  VOTED,  that 


(Name) 

the  of  this  corporation  is  hereby 

(Office) 

authorized  and  empowered  to  make,  enter  into,  sign,  seal  and  deliver  in  behalf  of  this 
corporation  a  contract  for   


(Describe  Service) 

with  the  City  of  Boston,  and  a  performance  bond  in  connection  with  said  contract. 

I  do  hereby  certify  that  the  above  is  a  true  and  correct  copy  of  the  record,  that 

said  vote  has  not  been  amended  or  repealed  and  is  in  full  force  and  effect  as  of  this  date, 

and  that  

(Name) 

is  the  duly  elected  

(Office) 

of  this  corporation. 
Attest: 

(Affix  Corporate  Seal  Here)   

(Clerk)  (Secretary)  of  the  Corporation 

APPROVED  AS  TO  FORM  BY  CORPORATION  COUNSEL  FEBRUARY,  1998 
THIS  FORM  IS  VOID  AND  WITHOUT  LEGAL  EFFECT  IF  ALTERED  IN  ANY  WAY 
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CITY  OF  BOSTON  /COUNTY  OF  SUFFOLK 


(FORM  CM-09) 


CONTRACTOR  CERTIFICATION* 

To  the  Official,  acting  in  the  name  and  behalf  of  the  City  of  Boston/County  of  Suffolk: 

A.  The  undersigned  agrees  to  furnish  all  labor  and  materials  and  to  perform  all  work  required  for: 


(Official  will  describe  work  here  prior  to  issue) 
in  accordance  with  the  terms  of  the  accompanying  contract  documents. 

A.   The  Contractor  is  a/an  

(Individual-Partnership-Corporation- Joint  Venture-Trust) 

1.   If  the  Contractor  is  a  Partnership,  state  name  and  residential  address  of  all  partners: 


2.  If  the  Contractor  is  a  Corporation,  state  the  following: 

Corporation  is  incorporated  in  the  State  of  

President  is  

Treasurer  is  

Place  of  business  is  

(Street) 

(City,  State  and  Zip  Code) 

3.  If  the  Contractor  is  a  Joint  Venture,  state  the  name  and  business  address  of  each  person,  firm 
or  company  that  is  party  to  the  joint  venture: 


A  copy  of  the  joint  venture  agreement  is  on  file  at 
and  will  be  delivered  to  the  Official  on  request. 
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(FORM  CM-09) 

4.   If  the  Contractor  is  a  Trust,  state  the  name  and  residential  address  of  all  Trustees: 


The  trust  document(s)  are  on  file  at  

and  will  be  delivered  to  the  Official  on  request. 

C.  If  the  business  is  conducted  under  any  title  other  than  the  real  name  of  the  owner,  state  the  time 
when,  and  place  where,  the  certificate  required  by  General  Laws,  c.110,  §5,  was  filed: 


D.  The  Taxpayer  Identification  Number*  of  the  contractor  (the  number  used  on  the  Employer's 
Quarterly  Federal  Tax  Return,  U.S.  Treasury  Department  Form  941)  is: 


*If  individual  use  Social  Security  Number:  . 

E.  Pursuant  to  M.G.L.  c.60,  §93,  the  undersigned  certifies  that  the  Collector-Treasurer  of  the  City  of 
Boston  may  withhold  from  amounts  owing  and  payable  to  the  Contractor  under  this  contract  any 
sums  owed  to  any  department  or  agency  of  the  City  of  Boston  which  remain  wholly  or  partially 
unpaid.  This  shall  include  but  not  be  limited  to  unpaid  taxes  and  assessments,  police  details,  and 
any  other  fees  and  charges  until  such  sums  owed  have  been  paid  in  full,  and  the  Collector- 
Treasurer  further  may  apply  any  amount  owing  and  payable  to  the  Contractor  to  satisfy  any 
monies  owed  to  the  City. 

F.  Pursuant  to  M.G.L.  C.62C,  §49A,  the  undersigned  certifies  under  the  penalties  of  perjury  that  to 
the  best  of  his/her  knowledge  and  belief  all  state  tax  returns  have  been  filed  and  all  state  taxes 
required  under  law  have  been  paid.  (NOTE:  The  Taxpayer  Identification  Number  will  be 
furnished  to  the  Massachusetts  Department  of  Revenue  to  determine  compliance  with  the  above- 
referenced  law). 
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(FORM  CM-09) 


Contractor: 


By:  

(Sign  Here) 

Business  Address:  

(Street) 


(City,  State  and  Zip  Code) 


NOTE:  This  statement  must  bear  the  written  signature  of  the  contractor. 

If  the  Contractor  is  an  individual  doing  business  under  a  name  other  than  his  own  name  this  statement 
must  so  state,  giving  the  address  of  the  individual. 

If  the  Contractor  is  a  partnership  this  statement  must  be  signed  by  a  general  partner  designated  as  such. 

If  the  Contractor  is  a  corporation,  trust  or  joint  venture  this  statement  must  be  signed  by  a  duly 
authorized  officer  or  agent  of  such  corporation,  trust  or  joint  venture. 


APPROVED  AS  TO  FORM  BY  CORPORATION  COUNSEL  FEBRUARY,  1998 
THIS  FORM  IS  VOID  AND  WITHOUT  LEGAL  EFFECT  IF  ALTERED  IN  ANY  WAY 
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(FORM  CM-07) 


CITY  OF  BOSTON/COUNTY  OF  SUFFOLK 

BID  RESPONSE  FORM 

BIDDER'S  NAME:  

(Full  legal  name  of  Bidder) 

PLACE  OF  BUSINESS:  

BIDDER'S  CONTACT  PERSON:  TEL:  

To  the  Official,  acting  in  the  name  and  behalf  of  the  City  of  Boston/County  of  Suffolk: 

A.    Summary  Of  Supplies/Services  Subject  To  Bid 

The  undersigned  proposes  to  furnish  the  specified  supplies  or  services  and  to  perform  all 
work  required  for: 


(Official  will  describe  here  services  or  supplies  to  be  procured  prior  to  issue  of  Invitation  For 
Bids;  to  be  identical  with  Purchase  Description  and  Specifications) 

in  accordance  with  the  terms  of  the  accompanying  Advertisement,  Purchase  Description  and 
Specifications  and  other  contract  documents,  with  special  reference  to  the  Invitation  For  Bids, 
the  terms  of  which  are  incorporated  herein,  all  of  which  have  been  provided  by  the  City. 

Notice  To  Bidder:  Bidders  must  itemize  any  deviation  from  original 
specifications  on  a  separate  sheet.  Catalogs  or  brochures  will  not  be  accepted  as 
sole  compliance  with  this  requirement  unless  they  also  include  complete 
technical  information. 


B.    Documents  Included 

In  addition  to  this  Bid  Response  Form,  this  bid  includes  the  following  documents  supplied  by 
the  Bidder  [List  Below]: 


C.    Price  Bid 

The  total  bid  price  for  this  contract  is:  

(in  words  &  figures;  may  attach  separate  schedule) 
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(FORM  CM-07) 

In  response  to  the  Price  Requirements  in  the  Purchase  Description  and  Specifications,  the 
price  components  of  the  bid  price  are: 


(Complete  as  required  in  Price  Requirements:  e.g.,  rates,  price  changes,  first  fiscal  year, 
total  contract  period,  etc.  May  attach  separate  schedule.) 

The  names  and  address  of  all  persons  interested  in  this  bid  as  principals  other  than  the 
undersigned  are: 


D.  References: 

Notice  To  Bidder:  Failure  to  provide  the  following  information,  if  required  in  the 
Purchase  Description  and  Specifications,  will  result  in  a  non-responsive  bid. 

1.    List  three  or  more  contracts  on  which  you  served  as  contractor  or  have  provided  goods 
and  supplies,  as  the  case  may  be,  within  the  past  two  (2)  years  (unless  a  lesser  or  greater 
period  is  specified  by  the  Official)  for  work  of  similar  character  as  required  in  the 
Purchase  Description  and  Specifications  in  this  Invitation  For  Bids. 

Reference  1 

Scope  of  Contract:   

Company  or  Entity:   

Contact  Name  &  Phone  #:   

Amount  of  Contract:   

Reference  2 

Scope  of  Contract:   

Company  or  Entity:   

Contact  Name  &  Phone  #:   

Amount  of  Contract:   

Reference  3 

Scope  of  Contract:   

Company  or  Entity:   

Contact  Name  &  Phone  #:   

Amount  of  Contract:   
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2.    Bank  reference(s): 

Name  of  Bank: 


(FORM  CM-07) 

Telephone  No.: 


E.    Legal  Form  Of  Business  Entity 

The  bidder  is  a/an  

(Individual-Partnership-Corporation-Joint  Venture-Trust) 

1.    If  the  bidder  is  a  Partnership,  state  name  and  residential  address  of  all  general  and 
limited  partners: 


2.  If  the  bidder  is  a  Corporation,  state  the  following: 

Corporation  is  incorporated  in  the  State  of  

President  is  

Treasurer  is  

Place  of  business  is  

(Street) 

(City,  State  and  Zip  Code) 

3.  If  the  bidder  is  a  Joint  Venture,  state  the  name  and  business  address  of  each  person,  firm 
or  company  that  is  party  to  the  joint  venture: 


A  copy  of  the  joint  venture  agreement  is  on  file  at  

and  will  be  delivered  to  the  Official  on  request. 

4.    If  the  bidder  is  a  Trust,  state  the  name  and  residential  address  of  all  Trustees: 


A  copy  of  the  trust  documents  are  on  file  at  _ 
and  will  be  delivered  to  the  Official  on  request. 
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(FORM  CM-07) 


F.    If  the  business  is  conducted  under  any  title  other  than  the  real  name  of  the  owner,  state  the  time 
when,  and  place  where,  the  certificate  required  by  General  Laws,  Chapter  110,  §5  was  filed: 


G.    The  Taxpayer  Identification  Number*  of  the  bidder  (the  number  used  on  the  Employer's 
Quarterly  Federal  Tax  Return,  U.S.  Treasury  Department  Form  941)  is: 


*If  individual,  use  Social  Security  Number:  

H.  Have  been  in  business  under  present  business  name  years. 

I.  Ever  failed  to  complete  any  work  awarded?  

If  answer  is  yes,  state  circumstances:  


J.     Pursuant  to  M.G.L.  c.60,  §93,  the  undersigned  understands  and  agrees  that  if  a  contract  is 
awarded  to  the  bidder,  that  the  Collector-Treasurer  of  the  City  of  Boston  may  withhold  from 
amounts  owing  and  payable  under  any  contract  awarded  to  a  successful  bidder  any  and  all  sums 
owed  to  any  department  or  agency  of  the  City  of  Boston  which  remain  wholly  or  partially 
unpaid.  This  shall  include  but  not  be  limited  to  unpaid  taxes  and  assessments,  police  details,  and 
any  other  fees  and  charges  until  such  sums  owed  have  been  paid  in  full,  and  the  Collector- 
Treasurer  further  may  apply  any  amounts  owing  and  payable  under  any  contract  awarded  to  the 
successful  bidder  to  satisfy  any  monies  owed  to  the  City. 

K.    Pursuant  to  M.G.L.  C.62C,  §49A,  the  undersigned  certifies  under  the  penalties  of  perjury  that  to 
the  best  of  his/her  knowledge  and  belief  all  state  tax  returns  have  been  filed  and  that  all  state 
taxes  required  under  law  have  been  paid.  (NOTE:  The  Taxpayer  Identification  Number  will  be 
furnished  to  the  Massachusetts  Department  of  Revenue  to  determine  compliance  with  the  above- 
referenced  law.) 

L.    The  undersigned  certifies  under  penalties  of  perjury  that  this  bid  or  proposal  has  been  made  and 
submitted  in  good  faith  and  without  collusion  or  fraud  with  any  other  person.  As  used  in  this 
certification,  the  word  "person"  shall  mean  any  natural  person,  business,  partnership, 
corporation,  union,  committee,  club,  or  other  organization,  entity  or  group  of  individuals. 
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(FORM  CM-07) 


Bidder: 


By:  

(Sign  Here) 

Business  Address:  


(Street) 


(City,  State,  Zip  Code) 


NOTE:  THIS  BID  MUST  BEAR  THE  WRITTEN  SIGNATURE  OF  THE  BIDDER. 

If  the  bidder  is  an  individual  doing  business  under  a  name  other  than  his  own  name  the  bid  must  so  state, 
giving  the  address  of  the  individual. 

If  the  bidder  is  a  partnership,  the  bid  must  be  signed  by  a  partner  designated  as  such. 

If  the  bidder  is  a  corporation,  trust  or  joint  venture  the  bid  must  be  signed  by  a  duly  authorized  officer  or 
agent  of  such  corporation,  trust  or  joint  venture. 


APPROVED  AS  TO  FORM  BY  CORPORATION  COUNSEL  FEBRUARY,  1998 
THIS  FORM  IS  VOID  AND  WITHOUT  LEGAL  EFFECT  IF  ALTERED  IN  ANY  WAY 
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CB  Form  8 


STATE  TAX  RETURN  CERTIFICATE 


The  City  of  Boston  is  subject  to  Section  49A  of  Chapter  62C  of  the  Massachusetts 
General  Laws  which  provides,  in  subsection  (b),  "[t]hat  no  contract  or  other  agreement  for  the 
purposes  of  providing  goods,  services  or  real  estate  space  ...  shall  be  entered  into,  renewed  or 
extended  with  any  person  unless  such  person  certifies  in  writing,  under  the  penalties  of  perjury, 
that  had  complied  with  all  laws  of  the  commonwealth  relating  to  taxes." 


Pursuant  to  M.G.L.  Chapter  62C,  Section  49A,  I  certify  under  the  penalties  of  perjury,  that  to 
my  best  knowledge  and  belief,  I  have  filed  all  state  tax  returns  and  paid  all  state  taxes  required 
under  law. 


Federal  Identification  # 


Approval  of  a  contract  or  other  agreement  will  not  be  granted  unless  this  certificate  is  signed  by 
the  bidder. 

Social  Security  number  of  Federal  Identification  number,  as  applicable,  will  be  furnished  to  the 
Massachusetts  Department  of  Revenue  to  determine  compliance  with  the  above-referenced  law. 


CERTIFICATION 


Name  of  Bidder  or  Proposer 


Authorized  Signature  of 
Bidder  or  Proposer 


Social  Security  # 


Date 
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(FORM  CM-05) 
PERFORMANCE  BOND 


The  undersigned  surety  company  hereby  binds  itself,  its  successors  and  assigns  to 

pay  to  the  City  of  Boston  the  sum  of  

($  )  dollars. 

This  obligation  is  upon  the  condition  that  if  the  party(s)  designated  in  the  contract 
attached  hereto  as  Contractor  and  all  subcontractors  under  such  contract  shall  faithfully 
furnish  and  perform  everything  required  to  be  furnished  and  performed  by  them  under 
such  contract,  and  for  all  labor  performed  or  furnished,  and  for  all  materials  used  in  the 
carrying  out  of  such  contract,  then  this  obligation  shall  become  and  be  null  and  void; 
otherwise  it  shall  be  and  remain  in  full  force  and  effect. 

Signed,  and  sealed  and  delivered  this  day  of  ,  . 

PRINCIPAL:   SURETY:  


By   By_ 


Name  Attorney-in-fact 

(Affix  Corporate  Seal  Here) 

Bonding  Company  is  Incorporated  in  State  of  

President  is  

Treasurer  is  

Place  of  business  of  Bonding  Corporation  in  Massachusetts  is  


APPROVED  AS  TO  FORM  BY  CORPORATION  COUNSEL  FEBRUARY,  1998 
THIS  FORM  IS  VOID  AND  WITHOUT  LEGAL  EFFECT  IF  ALTERED  IN  ANY  WAY 
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NOTIFICATION  TO  BE  INCLUDED  ON  THE  RFP 
INQUIRIES  AND  ANSWERS  MAILING  LIST  LOG  SHEET 


Per  the  Provisions  of  sections  '3.15'  and  '3.17'  of  this  RFP,  prospective  proposers  that  wish  to 
receive  (from  the  City)  RFP  related  correspondence  which  is  generated  by  the  City  on  those 
times  and  dates  after  the  Mandatory  Proposers'  Conference  must  complete  and  deliver  or 
mail  the  log  sheet  entitled  'NOTIFICATION  TO  BE  INCLUDED  ON  THE  RFP  INQUIRIES 
AND  ANSWERS  MAILING  LIST'  to  the  address  set  forth  in  section  3.11  of  this  RFP. 
Prospective  proposers  may,  alternately,  submit  the  completed  form  to  the  City  at  the 
Proposers'  Conference. 


A  copy  of  this  log  sheet  is  provided  on  the  following  page. 
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NOTIFICATION  TO  BE  INCLUDED  ON  THE  RFP 
INQUIRIES  AND  ANSWERS  MAILING  LIST  LOG 


INSTRUCTIONS:  Per  the  provisions  of  sections  '3.15'  and  '3.17'  of  this  RFP, 

prospective  proposers  that  wish  to  receive  (from  the  City)  RFP  related  correspondence  which 
is  generated  on  any  times  and  dates  after  the  Mandatory  Proposers'  Conference  must  deliver 
or  mail  this  completed  log  sheet  to  the  following  address: 


Ms.  Gina  Fiandaca 
Director 

BTD/Office  of  the  Parking  Clerk 

Room  224 

One  City  Hall  Plaza 

Boston.,  MA  02201 


Alternately,  prospective  proposers  may  submit  the  completed  form  to  the  City  at  the 
Proposers'  Conference. 


PROSPECTIVE  PROPOSER  INFORMATION: 


Company  Name: 


Contact  Person  : 


Title  : 


Mailing  Address  j_ 


Telephone  :       £  \ 

Fax:  (  ]_ 
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COPIES  OF  REQUIRED  RESPONSE  FORMS 


AND  QUESTIONNAIRES 


As  noted  in  section  '8.4'  of  this  RFP  document,  copies  of  response  forms  and 
questionnaires  are  provided  on  the  following  pages. 

Where  not  self-explanatory,  instructions  to  proposers  regarding  the  provision  of  such 
information  are  provided  with  the  form  or  questionnaire.  As  a  general  guideline,  the 
proposer's  provision  of  said  information  shall  be  detailed,  comprehensive  and  clear. 

Please  note  that  forms  number  1  through  3  as  they  appear  in  this  RFP  have  been  reduced, 
for  packaging  purposes,  from  their  actual  size  of  8.5"  X  14"  to  8.5"  X  11".  'Full  Size' 
copies  of  these  forms,  and  additional  copies  of  all  other  forms,  shall  be  made  available  at 
the  Proposer's  Conference  or  at  any  other  time  at  the  request  of  a  proposer.  Also, 
proposers  may  reproduce  or  use  a  facsimile  of  the  forms  and  questionnaires.  However, 
forms  number  1  through  3  may  be  difficult  to  reproduce,  i.e.,  copy,  due  to  copy 
enlargement  considerations. 

Below  is  a  listing  of  the  ten  (10)  response  forms  that  appear  on  the  following  pages  (page 
numbers  are  indicated): 

Form  A:         Minimum  Evaluation  Criteria  Response  Form  (p.  527) 

Form  #1:        5  Large  Scale,  Full  Service  Clients  For  Primary  Parking  Ticket  Processing 
That  Are  Most  Similar  And  Comparable  To  Boston:  Summary  Data  (p. 
551) 

Form  #2:        Additional  10  PVPMISS  Clients  For  Primary  Ticket  Processing  (p.  562) 

Form  #3:        5  Large  Scale,  Full  Service  Clients  For  Primary  Parking  Ticket  Processing 
That  Are  Most  Similar  And  Comparable  To  Boston:  Scope  of  Services 
Overview 

Form  #4:        Proposer  PVPMISS  Experience  Form  (p.  564) 

Form  #5:        PVPMISS  Employee  Background  Form  (p.  565) 

Form  #6:        Motor  Vehicle  Agency  Interface  Experience  Form  (p.  571) 

Form  #7:        PVPMISS  Proposer  Overview  Form  (p.  577) 

Form  #8:        PVPMISS  Personnel  Matrix  Form  (p.  579) 

Form  #9:        Data  Center  Hardware  and  Technical  Environment  (p.  581) 

Form  #10       Hand-Held  Ticket  Writing  Devices  (p.  582) 
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INSTRUCTIONS  FOR  THE  COMPLETION  OF  FORM  A 


MINIMUM  EVALUATION  CRITERIA  RESPONSE  FORM 


Complete  Parts  A  and  B  of  this  form  to  substantiate  two  of  the  required  total  four 
years  experience  processing  500,000  parking  tickets  annually.  Parts  A  and  B  of  this 
form  are  intended  to  allow  proposers  to  list  multiple  clients  if  a  proposer  did  not 
process  all  500,000  parking  tickets  for  a  single  client  for  two  of  the  four  years. 

Complete  parts  C  and  D  of  this  form  to  substantiate  the  remaining  two  years  of  the 
required  total  four  years  experience  processing  500,000  parking  tickets  annually. 
Parts  C  and  D  are  intended  to  allow  proposers  to  list  a  single  client  for  whom  the 
proposer  processed  500,000  parking  tickets  annually. 

If  the  proposer  has  experience  processing  500,000  parking  tickets  annually  for  a 
single  client  for  all  four  years  of  the  required  experience,  Parts  A  and  B  should  be 
completed  listing  the  single  client  in  the  space  provided  for  'Name  of  Client'.  Parts 
C  and  D  should  be  completed  as  indicated  above. 
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FORMA 

(page  1  of  24) 

MINIMUM  EVALUATION  CRITERIA  RESPONSE  FORM 


Name  of  Proposer:   

1.       Proposer  Experience 
Part  A 

Instructions: 

Use  one  form  per  year. 

For  each  system,  subsystem  or  service  listed  on  the  following  pages,  indicate  the 
client  to  which  this  item  was  provided/not  provided  by  listing  the  client  number 
(as  indicated  on  this  page  below)  in  the  space  provided  on  the  following  pages. 
Date:  Indicate  dates  of  service  for  each  client. 

Year  1:  

Total  #  of  parking  tickets  processed  for  this  year  (combined  for  all  clients):  

Name  of  Client                                    Annual  #  Tickets  Processed  Dates 
#1    

#2    

#3    

#4    

#5    

#6    

#7    

#8    
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(attach  additional  pages  if  necessary) 


MINIMUM  EVALUATION  CRITERIA  RESPONSE  FORM  (page  2  of  24) 

1.       Proposer  Experience 
Part  A  (cont.) 

RFP  Systems,  Subsystems  and  Services  Provided/Not  Provided: 

System/Subsystem/Service  Provided  Not  Provided 

1.        System,  Operational  and  Functional 
Requirements  of  a  Comprehensive 
and  Integrated  PVPMISS 


2.        Changes  to  Specifications  and 

Requirements  and  the  Effective  and 
Efficient  Accommodation  of  Changes 


3.        Parking  Ticket  Pick-up, 
Receipt  and  Control 


4.        Ticket  Data  Entry 


5.        Updating  Tickets  to  On-Line 
and  Master  Files 


6.        Lockbox  Processing  Functions 


7.        On-Line,  Real-Time,  'Point  of  Sale' 
Processing  System 


8.        Required  Screen  Data  for  General  and 

Universal  Inquiry  and  Customer  Service  Functions 


9.        On-Line,  Real-Time  Claims  Processing  System 
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MINIMUM  EVALUATION  CRITERIA  RESPONSE  FORM  (page  3  of  24) 

I.  Proposer  Experience 
Part  A  (cont.) 

RFP  Systems,  Subsystems  and  Services  Provided/Not  Provided: 
System/Subsystem/Service  Provided  Not  Provided 

10.      RMV  Interface  System 

II.  Dunning  Notice  System  and  Services 

12.  Boot  and  Tow  System 

13.  Abandoned  Vehicle  System 

14.  On-Line  Multiple  Vehicle-Single 
Owner/Entity  System 

15.  Parking  Meter  Management  System 

16.  Sign  Management  System 

17.  Automated  Interactive  Voice 
Response  System 

18.  Automated  Refund  System 

19.  Management  Information  System 
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MINIMUM  EVALUATION  CRITERIA  RESPONSE  FORM  (page  4  of  24) 

1.       Proposer  Experience 
Part  A  (cont.) 

RFP  Systems,  Subsystems  and  Services  Provided/Not  Provided: 
System/Subsystem/Service  Provided  Not  Provided 

20.  Production  Schedules 

21.  Network  Capability  and  Other  Equipment, 
Service  and  Supply  Requirements 

22.  On-Line  System  Availability 

23.  File  Archive 

24.  Resident  Permit  Parking  System 

25.  Provision  of  Complete  Services  to 
All  Tickets  on  the  Database 

26.  System  Documentation  and 
User  Requirements 

27.  Performance  Reporting 

28.  Security 

29.  Complete  and  Comprehensive  Back-Up 
of  all  Systems  and  Files  and  Alternative 
Processing  Arrangements 
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MINIMUM  EVALUATION  CRITERIA  RESPONSE  FORM  (page  5  of  24) 

1.       Proposer  Experience 
Part  A  (cont.) 

RFP  Systems,  Subsystems  and  Services  Provided/Not  Provided: 
System/Subsystem/Service  Provided  Not  Provided 

30.  Training 

31.  Capacity  and  Volumes 

32.  Test  System 

33.  Recovery  from  Catastrophic  Failure 

34.  Organization,  Plan  of  Services 
and  Personnel 

35.  Secondary  Collections 

36.  Conversion 

37.  Hand-Held  Ticket  Writing  Devices 

38.  Document  Image  Processing  and 
Workflow  System 

39.  Traffic  Management  Permitting  System 


40.  Red  Light  Running  Program 


276 


MINIMUM  EVALUATION  CRITERIA  RESPONSE  FORM  (page  6  of  24) 


1.       Proposer  Experience 
Part  B 

Instructions: 

Use  one  form  per  year. 

For  each  system,  subsystem  or  service  listed  on  the  following  pages,  indicate  the 
client  to  which  this  item  was  provided/not  provided  by  listing  the  client  number 
(as  indicated  on  this  page  below)  in  the  space  provided  on  the  following  pages. 
Date:  Indicate  dates  of  service  for  each  client. 

Year  2:   

Total  #  of  parking  tickets  processed  for  this  year  (combined  for  all  clients):  

Name  of  Client                                    Annual  #  Tickets  Processed  Dates 
#1    


#2 


#3. 


#4 


#5. 


#6. 


#7 


#8. 


(attach  additional  pages  if  necessary) 


277 


MINIMUM  EVALUATION  CRITERIA  RESPONSE  FORM  (page  7  of  24) 

1.       Proposer  Experience 
Part  B  (cont.) 

RFP  Systems,  Subsystems  and  Services  Provided/Not  Provided: 

System/Subsystem/Service  Provided  Not  Provided 

1.        System,  Operational  and  Functional 
Requirements  of  a  Comprehensive 
and  Integrated  PVPMISS 


2.        Changes  to  Specifications  and 

Requirements  and  the  Effective  and 
Efficient  Accommodation  of  Changes 


3.        Parking  Ticket  Pick-Up, 
Receipt  and  Control 


4.        Ticket  Data  Entry 


5.        Updating  Tickets  to  On-Line  and 
Master  Files 


6.        Lockbox  Processing  Functions 


7.        On-Line,  Real-Time,  'Point  of  Sale' 
Payment  Processing  System 


8.        Required  Screen  Data  for  General  and 

Universal  Inquiry  and  Customer  Service  Functions 


9.        On-Line,  Real-Time  Claims  Processing  System 
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MINIMUM  EVALUATION  CRITERIA  RESPONSE  FORM  (page  8  of  24) 

I.  Proposer  Experience 
Part  B  (cont.) 

RFP  Systems,  Subsystems  and  Services  Provided/Not  Provided: 
System/Subsystem/Service  Provided  Not  Provided 

10.      RMV  Interface  System 

II.  Dunning  Notice  System  and  Services 

12.  Boot  and  Tow  System 

13.  Abandoned  Vehicle  System 

14.  On-Line  Multiple  Vehicle-Single 
Owner/Entity  System 

15.  Parking  Meter  Management  System 

16.  Sign  Management  System 

17.  Automated  Interactive  Voice 
Response  System 

18.  Automated  Refund  System 

19.  Management  Information  System 
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MINIMUM  EVALUATION  CRITERIA  RESPONSE  FORM  (page  9  of  24) 

1.       Proposer  Experience 
Part  B  (cont.) 

RFP  Systems,  Subsystems  and  Services  Provided/Not  Provided: 
System/Subsystem/Service  Provided  Not  Provided 

20.  Production  Schedules 

21.  Network  Capability  and  Other  Equipment, 
Service  and  Supply  Requirements 

22.  On-Line  System  Availability 

23.  File  Archive 

24.  Resident  Permit  Parking  System 

25.  Provision  of  Complete  Services  to 
All  Tickets  on  the  Database 

26.  System  Documentation  and 
User  Requirements 

27.  Performance  Reporting 

28.  Security 

29.  Complete  and  Comprehensive  Back-Up 
of  all  Systems  and  Files  and  Alternative 
Processing  Arrangements 
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MINIMUM  EVALUATION  CRITERIA  RESPONSE  FORM  (page  10  of  24) 

1.       Proposer  Experience 
Part  B  (cont.) 

RFP  Systems,  Subsystems  and  Services  Provided/Not  Provided: 
System/Subsystem/Service  Provided  Not  Provided 

30.  Training 

31.  Capacity  and  Volumes 

32.  Test  System 

33.  Recovery  from  Catastrophic  Failure 

34.  Organization,  Plan  of  Services 
and  Personnel 

35.  Secondary  Collections 

36.  Conversion 

37.  Hand-Held  Ticket  Writing  Devices 

38.  Document  Image  Processing  and 
Workflow  System 

39.  Traffic  Management  Permitting  System 


40.      Red  Light  Running  Program 
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MINIMUM  EVALUATION  CRITERIA  RESPONSE  FORM  (page  11  of  24) 


1.        Proposer  Experience 
Part  C 

Instructions: 

Use  this  form  to  substantiate  experience  processing  at  least  500,000  parking 
tickets  annually  for  a  SINGLE  CLIENT.  (Use  this  form  for  first  of  two 
required  years  processing  500,000  tickets  annually  for  a  single  client).  Use  one 
form  per  client  per  year. 

Indicate  with  an  "X"  for  each  item  provided  or  not  provided  for  each  client. 
Date:  Indicate  date  service  for  this  item  commenced. 

Name  of  Client:  

Address:  

Dates  of  Service        From:    To:   

Annual  #  of  Parking  Tickets  Processed:   

RFP  Systems,  Subsystems  and  Services  Provided: 

System/Subsystem/Service  Provided  Not  Provided  Date 

1.        System,  Operational  and  Functional 
Requirements  of  a  Comprehensive 
and  Integrated  PVPMISS 


1.        Changes  to  Specifications  and 

Requirements  and  the  Effective  and 
Efficient  Accommodation  of  Changes 


2.        Parking  Ticket  Pick-Up, 
Receipt  and  Control 


3.        Ticket  Data  Entry 


4.       Updating  Tickets  to  On-Line  and 
Master  Files 
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MINIMUM  EVALUATION  CRITERIA  RESPONSE  FORM  (page  12  of  24) 

1.       Proposer  Experience 
Part  C  (cont.) 

RFP  Systems,  Subsystems  and  Services  Provided/Not  Provided: 
System/Subsystem/Service  Provided  Not  Provided  Date 

5.        Lockbox  Processing  Functions 


7.        On-Line,  Real-Time,  'Point  of  Sale' 
Payment  Processing  System 


8.        Required  Screen  Data  for  General  and 

Universal  Inquiry  and  Customer  Service  Functions 


9.        On-Line,  Real-Time  Claims  Processing  System 


10.      RMV  Interface  System 


11.      Dunning  Notice  System  and  Services 


12.      Boot  and  Tow  System 


13.      Abandoned  Vehicle  System 


14.      On-Line  Multiple  Vehicle-Single 
Owner/Entity  System 
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15.      Parking  Meter  Management  System 


16.      Sign  Management  System 
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MINIMUM  EVALUATION  CRITERIA  RESPONSE  FORM  (page  13  of  24) 

1.       Proposer  Experience 
Part  C  (cont.) 

RFP  Systems,  Subsystems  and  Services  Provided/Not  Provided: 

System/Subsystem/Service  Provided  Not  Provided  Date 

17.      Automated  Interactive  Voice 
Response  System 


18.      Automated  Refund  System 


19.      Management  Information  System 


20.      Production  Schedules 


21.      Network  Capability  and  Other  Equipment, 
Service  and  Supply  Requirements 


22.      On-Line  System  Availability 


23.      File  Archive 


24.      Resident  Permit  Parking  System 


25.      Provision  of  Complete  Services  to 
All  Tickets  on  the  Database 
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System  Documentation  and 
User  Requirements 


MINIMUM  EVALUATION  CRITERIA  RESPONSE  FORM  (page  14  of  24) 

1.       Proposer  Experience 
Part  C  (cont.) 

RFP  Systems,  Subsystems  and  Services  Provided/Not  Provided: 
System/Subsystem/Service  Provided  Not  Provided  Date 

27.      Performance  Reporting 


28.  Security 


29.  Complete  and  Comprehensive  Back-Up 
of  all  Systems  and  Files  and  Alternative 
Processing  Arrangements 


30.  Training 


31.      Capacity  and  Volumes 


32.      Test  System 


33.      Recovery  from  Catastrophic  Failure 


34.      Organization,  Plan  of  Services 
and  Personnel 


35.      Secondary  Collections 
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36.  Conversion 
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MINIMUM  EVALUATION  CRITERIA  RESPONSE  FORM  (page  15  of  24) 

1.       Proposer  Experience 
Part  C  (cont.) 

RFP  Systems,  Subsystems  and  Services  Provided/Not  Provided: 
System/Subsystem/Service  Provided  Not  Provided  Date 

37.      Hand-Held  Ticket  Writing  Devices 


38.      Document  Image  Processing  and 
Workflow  System 


39.      Traffic  Management  Permitting  System 


40.      Red  Light  Running  Program 
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MINIMUM  EVALUATION  CRITERIA  RESPONSE  FORM  (page  16  of  24) 


1.        Proposer  Experience 
Part  D 

Instructions: 

Use  this  form  to  substantiate  experience  processing  at  least  500,000  parking 
tickets  annually  for  a  SINGLE  CLIENT.  (Use  this  form  for  second  of  two 
required  years  processing  500,000  tickets  annually  for  a  single  client).  Use  one 
form  per  client  per  year. 

Indicate  with  an  "X"  for  each  item  provided  or  not  provided  for  each  client. 
Date:  Indicate  date  service  for  this  item  commenced. 

Name  of  Client:  

Address:  

Dates  of  Service        From:    To:   

Annual  #  of  Parking  Tickets  Processed:   

RFP  Systems,  Subsystems  and  Services  Provided: 

System/Subsystem/Service  Provided  Not  Provided  Date 

1.        System,  Operational  and  Functional 
Requirements  of  a  Comprehensive 
and  Integrated  PVPMISS 


2.        Changes  to  Specifications  and 

Requirements  and  the  Effective  and 
Efficient  Accommodation  of  Changes 


3.        Parking  Ticket  Pick-Up, 
Receipt  and  Control 


4.        Ticket  Data  Entry 


5.       Updating  Tickets  to  On-Line  and 
Master  Files 
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MINIMUM  EVALUATION  CRITERIA  RESPONSE  FORM  (page  17  of  24) 

1.       Proposer  Experience 
Part  D  (cont.) 

RFP  Systems,  Subsystems  and  Services  Provided/Not  Provided: 
System/Subsystem/Service  Provided  Not  Provided  Date 

6.        Lockbox  Processing  Functions 


7.        On-Line,  Real-Time,  'Point  of  Sale' 
Payment  Processing  System 


8.        Required  Screen  Data  for  General  and 

Universal  Inquiry  and  Customer  Service  Functions 


9.        On-Line,  Real-Time  Claims  Processing  System 


10.      RMV  Interface  System 


11.      Dunning  Notice  System  and  Services 


12.      Boot  and  Tow  System 


13.      Abandoned  Vehicle  System 


14.      On-Line  Multiple  Vehicle-Single 
Owner/Entity  System 
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15.      Parking  Meter  Management  System 


16.      Sign  Management  System 
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MINIMUM  EVALUATION  CRITERIA  RESPONSE  FORM  (page  18  of  24) 

1.       Proposer  Experience 
Part  D  (cont.) 

RFP  Systems,  Subsystems  and  Services  Provided/Not  Provided: 

System/Subsystem/Service  Provided  Not  Provided  Date 

17.      Automated  Interactive  Voice 
Response  System 


18.      Automated  Refund  System 


19.      Management  Information  System 


20.      Production  Schedules 


21.      Network  Capability  and  Other  Equipment, 
Service  and  Supply  Requirements 


22.      On-Line  System  Availability 


23.      File  Archive 


24.      Resident  Permit  Parking  System 


25.      Provision  of  Complete  Services  to 
All  Tickets  on  the  Database 
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System  Documentation  and 
User  Requirements 


MINIMUM  EVALUATION  CRITERIA  RESPONSE  FORM  (page  19  of  24) 

1.       Proposer  Experience 
Part  D  (cont.) 

RFP  Systems,  Subsystems  and  Services  Provided/Not  Provided: 
System/Subsystem/Service  Provided  Not  Provided  Date 

27.      Performance  Reporting 


28.  Security 


29.  Complete  and  Comprehensive  Back-Up 
of  all  Systems  and  Files  and  Alternative 
Processing  Arrangements 


30.  Training 


31.      Capacity  and  Volumes 


32.      Test  System 


33.      Recovery  from  Catastrophic  Failure 


34.      Organization,  Plan  of  Services 
and  Personnel 


35.      Secondary  Collections 
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36.  Conversion 
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MINIMUM  EVALUATION  CRITERIA  RESPONSE  FORM  (page  20  of  24) 

1.       Proposer  Experience 
Part  D  (cont.) 

RFP  Systems,  Subsystems  and  Services  Provided/Not  Provided: 
System/Subsystem/Service  Provided  Not  Provided  Date 

37.      Hand-Held  Ticket  Writing  Devices 


38.      Document  Image  Processing  and 
Workflow  System 


39.      Traffic  Management  Permitting  System 


40.      Red  Light  Running  Program 
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MINIMUM  EVALUATION  CRITERIA  RESPONSE  FORM  (page  21  of  24) 

1.        Required  Systems/Subsystems/Services  -  Have  you  included  all  systems, 

subsystems  and  services,  as  defined  in  the  section  of  this  RFP  entitled  "Scope  of 
Services",  as  part  of  your  proposal? 

YES   NO  


3.        Proposal  Deposit  -  Have  you  submitted  a  proposal  deposit  in  the  form  of  a 
certified  check  drawn  on,  or  a  treasurer's  or  cashier's  check  issued  by,  a 
responsible  bank  or  trust  company  and  made  payable  to  the  City  of  Boston,  or  a 
proposal  bond  issued  by  a  surety  company  qualified  to  do  business  in  the 
Commonwealth  and  satisfactory  in  form  to  the  City?  Is  the  amount  of  such  check 
or  the  penal  sum  of  such  bond  $25,000  (twenty-five  thousand  dollars)?  Does  such 
proposal  deposit  accompany  the  original  signed  Technical  Proposal  received  at 
the  Transportation  Department/Office  of  the  Parking  Clerk? 

YES   NO  


4.        Performance  Bond  -  Do  you  agree  to  provide,  at  the  City's  discretion,  as  security 
to  guarantee  the  faithful  performance  of  any  contract  awarded  pursuant  to  this 
RFP  a  performance  bond  of  a  surety  company  authorized  to  do  business  in  the 
Commonwealth  and  satisfactory  in  form  to  the  Awarding  Authority  in  the  amount 
of  $1,000,000  (one  million  dollars)? 

YES   NO  
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MINIMUM  EVALUATION  CRITERIA  RESPONSE  FORM  (page  22  of  24) 


5.        Proposal  Format  -  Have  you  submitted  your  proposal  in  conformance  with  the 
requirements  set  forth  in  the  section  of  this  RFP  entitled  "Information  and 
Instructions  to  Proposers  Regarding  Submittal  of  the  Non-Cost  (Technical)  and 
Cost  Proposals  and  the  Evaluation  Thereof"  and  the  section  of  this  RFP  entitled 
"Submission  of  the  Complete  Proposal"?  Have  you  included  all  required  forms, 
responses  and  references?  Have  you  submitted  separate,  clearly  labeled  and 
sealed  technical  and  cost  proposals? 

YES   NO  


5.A.     Cost  Submittal  -  Have  you  submitted  your  cost  proposal  separate  from  your 

technical  proposal,  in  a  sealed  package  clearly  labeled  in  conformance  with  the 
requirements  set  forth  in  the  section  of  this  RFP  entitled  "Information  and 
Instructions  to  Proposers  Regarding  Submittal  of  the  Non-Cost  (Technical)  and 
Cost  proposals  and  the  Evaluation  Thereof?" 

YES   NO  


6.       Turnkey  -  -  Do  you  agree  to  provide  all  systems,  subsystems  and  services  as 

defined  in  the  section  of  this  RFP  entitled  "Scope  of  Services",  ready  to  operate  in 
a  production  environment,  on  July  1,  2010? 

YES   NO  
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MINIMUM  EVALUATION  CRITERIA  RESPONSE  FORM  (page  23  of  24) 


7.        Personnel  -  Have  you  included  all  of  the  required  RFP  Forms  and  detailed  current 
resumes  for  all  of  the  key  personnel  as  requested  in  this  RFP? 

YES   NO  


7.A.     Project  Team  -  Do  you  agree  that  the  City  shall  retain  the  right  to  interview  and 
approve/disapprove  any  potential  Boston  project  team  member  or  key  personnel? 
Additionally,  if  a  key  individual's  or  team  member's  performance  proves 
unsatisfactory  to  the  City  or  if  personality  conflicts  impair  performance,  do  you 
agree  that  the  City  reserves  the  right  to  require  that  person's  removal  from  the 
Boston  Team? 


YES   NO 


8.       Adaptability  -  Do  you  agree  to  adapt  and  upgrade  your  staffing,  equipment, 
software  and  other  resources  to  respond  to  and  fulfill  the  variable  needs  of  the 
City  throughout  the  course  of  any  contract  awarded  pursuant  to  this  RFP  without 
additional  cost  to  the  City? 

YES   NO  
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MINIMUM  EVALUATION  CRITERIA  RESPONSE  FORM  (page  24  of  24) 


9.        Financial  Strength  -  Is  your  firm  financially  solvent  (i.e.  currently  not  bankrupt 
and  currently  not  considering  filing  for  bankruptcy  protection)  and  have  you 
provided  documentation  to  support  that  fact?  At  a  minimum,  have  you  provided 
audited  financial  statements  for  each  of  the  three  (3)  most  recent  fiscal  years?  (If 
your  firm  is  a  subsidiary  of  a  larger  organization,  this  information,  if  available, 
should  be  provided  for  the  parent  and  the  proposing  entity.) 

YES   NO  


10.      User  Guides  and  Specifications  for  Program/System  Areas  and  Service  Areas 
(with  the  emphasis  on  system  areas)  -  Do  you  agree  to  provide  the  actual 
documentation  for  system,  subsystem  and  service  areas  (with  the  emphasis  on 
systems  and  subsystems)?  This  constitutes  your  description  and  provision  of 
actual  documentation  relative  to  each  RFP  system  or  service  function  such  as: 
user  guides/manuals  for  on-line  systems  viewing,  on-line  systems  processing, 
MIS  and  other  reports,  etc.;  user-oriented  system  processing  explanations;  user- 
oriented  criteria  and  condition  statements  for  system  activities,  events  and 
functions;  user-oriented  functional  specifications  and  descriptions  of  software 
programs  and  relationships  between  different  programs;  user-oriented 
descriptions  of  operational  service  functions;  etc.  In  the  event  that  certain 
information  represents  trade  secrets  or  proprietary  information,  do  you  agree  to 
make  said  material  available  to  the  City  at  a  location  to  be  determined  by  you,  so 
long  as  said  location  is  situated  within  approximately  a  one  (1)  mile  radius  of 
Boston  City  Hall?  Do  you  agree  to  allow  evaluators  unrestricted  access,  for  the 
purpose  of  review  and  'note  taking',  to  said  document  during  the  hours  of  9:00 
a.m.  and  5:00  p.m.,  Monday  through  Friday  (excluding  holidays),  during  the 
evaluation  phase  of  this  RFP?  (The  beforementioned  access  for  any  single  review 
visit  shall  be  arranged  a  minimum  of  twenty-four  (24)  hours  prior  to  said  visit.) 

YES   NO  
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FORM  #  1:    5  LARGE  SCALE,  FULL  SERVICE  CLIENTS  FOR  PRIMARY 

PARKING  TICKET  PROCESSING  THAT  ARE  MOST  SIMILAR  AND 
COMPARABLE  TO  BOSTON:  SUMMARY  DATA 

Instructions  for  Completion: 
(page  1  of  3  instructions) 


Introduction:  Provide  a  list  of  five  (5)  large-scale,  full  service  PVPMISS  clients  in 
which  the  requirements,  systems  and  services  for  the  clients  are  at  least  somewhat  similar 
and  comparable  to  the  requirements,  systems  and  services  reflected  in  this  RFP.  This  list 
should  also  be  limited  to  those  clients  for  which  you  provide  and  operate  the  primary 
computer  system  and  maintain  and  update  the  database  containing  the  parking  violations. 
If  you  provide  just  one  or  two  basic  systems  or  services  such  as  backlog  collections  or 
lockbox  services  for  a  client,  you  should  definitely  not  list  the  client  on  this  form.  If  data 
is  not  available  for  categories,  indicate  with  the  notation  -  N/A.  (You  may  provide 
information  on  clients  that  are  provided  specific  systems  and  services  that  are  similar  and 
comparable  to  those  required  by  Boston  on  additional  sheets  of  paper  /  pages.  Also,  if 
you  have  other  information  about  your  experience  that  could  not  be  easily  reflected  on 
this  form,  you  can  substitute  separate  sheets  of  paper  /  pages.  If  you  do  submit  additional 
sheets  of  paper  /  pages,  you  should  indicate  at  the  bottom  of  the  form  the  number  of 
additional  pages  that  have  been  attached  to  the  form.) 


Column  A:  Indicate  your  clients  that  are  most  similar  and  comparable  to  Boston  in 
terms  of  the  number  of  parking  tickets  and  the  RFP  PVPMISS  requirements  relative  to 
number,  size,  scope,  level  of  integration  and  complexity  of  the  systems  and  services. 

For  the  two  similar  to  Boston  clients,  please  try  to  provide  data  for  up  to  the  past  ten  (10) 
years  for  at  least  categories  'A'  through  'D'.  You  may,  particularly  for  the  older  years, 
use  'rough'  approximate  numbers  or  'rough'  estimates.  However,  if  you  use  'rough' 
approximate  or  estimated  numbers,  place  the  letter  'A'  in  front  of  the  number.  In  a  space 
prior  to  the  client's  name,  next  to  the  #  symbol,  indicate  the  client's  similarity  and 
comparability  to  Boston  by  ranking  the  clients  'V  through  '5'  in  terms  of  similarity  to 
Boston.  For  example,  the  client  with  the  number  '1'  prior  to  its  name  would  be  the  client 
that  is  most  similar  to  Boston  and  the  client  with  the  number  '5'  prior  to  its  name  would 
be  the  client  that  is  least  similar  to  Boston  of  the  five  clients. 
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FORM  #  1  Instructions,  page  2  of  3 

Column  B:  Provide  data  on  the  clients  for  the  past  years.  Indicate  with  a  CY  if  data  is 
for  a  calendar  year  or  FY  if  data  is  for  a  fiscal  year.  Also,  indicate  the  months  that  you 
provided  systems  and  services  under  contract  to  the  Client. 

Examples:  2008:  cy  /fy    x    .  7/2007  to  6/2008: 

2008:  cy  /fy   x    .  7/2007  to  12/2007; 

cv    x    /fy  ,  1/2008  to  8/2008. 

For  2000,  whether  calendar  or  fiscal  year,  if  you  are  continuing  to  provide  service  beyond 
the  month  indicated,  please  put  an  asterisk  next  to  the  year  (i.e.,  00*). 

Column  C:  In  this  column,  indicate  the  number  of  parking  tickets  issued.  (Do  not 
include  moving  violations.) 

Column  D:  Indicate  the  revenue  from  parking  tickets  fines  and  penalties.  (Do  not 
include  revenue  from  other  sources  such  as  but  not  limited  to,  moving  violations,  seizure 
fees,  tow  fees,  meter  revenue  and  storage  fees.) 

Column  E:  Indicate  the  number  of  discrete  payments  processed.  If  you  receive  partial 
payments  on  a  ticket  on  different  days,  you  could  count  it  as  two  payments  that  were 
processed. 

Column  F:  Indicate  the  total  number  of  discrete  requests  for  registrant  identification 
requests  to  all  RMV's  for  data  on  registrants  of  motor  vehicles  with  parking  tickets.  If 
you  made  requests  on  the  same  registration  six  different  times  during  the  year,  you  would 
count  this  as  six  requests.  (Do  not  include  requests  for  registrant  data  on  moving 
violations  or  other  types  of  violations.) 

Frequency:  You  should  indicate  the  normal  frequency  that  registrant  requests 
were  sent  to  the  registry,  i.e.,  daily,  weekly,  bi-weekly,  monthly,  bi-monthly,  quarterly, 
annually  or  if  your  response  does  not  fit  any  of  these  categories,  identify  the  time  period 
in  your  own  words. 

Column  G:  Indicate  the  number  of  parking  ticket  requests  that  were  accepted  and 
actually  "marked"  and  actually  "cleared"  for  non-renewal  of  a  driver's  license  or 
registration  by  the  Registry  or  Division  of  Motor  Vehicles.  (Do  not  include  requests  for 
registrant  data  on  moving  violations  or  other  types  of  violations.) 

Frequency:  You  should  indicate  the  normal  frequency  that  parking  ticket 
requests  for  "marks"  and  "clears"  were  sent  to  the  registry,  i.e.,  daily,  weekly,  bi-weekly, 
monthly,  bi-monthly,  quarterly,  annually  or  if  your  response  does  not  fit  any  of  these 
categories,  identify  the  time  period  in  your  own  words. 
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FORM  #  1  Instructions,  page  3  of  3 


Column  H:  Indicate  the  number  of  parking  ticket  "dunning"  notices  that  were  mailed. 
Do  not  include  correspondence  notices  of  any  type  (i.e.,  Resident  Permit  notices, 
Abandoned  Vehicle  notices,  etc.)  or  hearing  requests  unless  the  hearing  request  was 
designed  as  a  "dunning"  notice.  The  number  must  reflect  the  number  of  notices  and  not 
the  number  of  tickets  that  appeared  on  notices. 

Frequency:  You  should  indicate  the  normal  frequency  that  notices  were  mailed, 
i.e.,  daily,  weekly,  bi-weekly,  monthly,  bi-monthly,  quarterly,  annually  or  if  your 
response  does  not  fit  any  of  these  categories,  identify  the  time  period  in  your  own  words. 
If  your  system  allowed  clients  to  make  selections  for  mailings  from  various  frequencies 
and  combination  of  frequencies  of  which  a  daily  frequency  was  an  option,  use  the  word, 
"flexible"  under  the  frequency  category. 

Ticket:  Indicate  with  an  "X"  if  your  system  routinely  generated  notices  based  on 
ticket-level  criteria. 

Plate:  Indicate  with  an  "X"  if  your  system  routinely  generated  notices  based  on 
plate-level  criteria. 

Column  I:  The  first  number  should  indicate  the  number  of  vehicles  that  were  booted 
and/or  towed  for  seizure  because  a  specified  number  of  tickets  remained  unpaid.  The 
second  number  should  indicate  the  number  of  unpaid  tickets  that  qualified  a  vehicle  for 
such  seizure. 

Column  J:  Indicate  the  number  of  tows  performed  due  to  a  distinct  occurrence  where  a 
vehicle  is  parked  illegally  such  as  in  a  tow  zone  or  at  a  hydrant. 
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1090o  FORM  #1 

*  5  LARGE  SCALE.  FULL  SERVICE  CLIENTS  FOR  PRIMARY  PARKING  TICKET  PROCESSING  THAT  ARE  MOST  SIMILAR  &  COMPARABLE  TO  BOSTON:  SUMMARY  DATA 


F. 

INDIVIDUAL  REQUESTS  FOR 
REGISTRY  DATA  FREQUENCY 


2009    /  /  06    .    .    09    .    .    06    .    .    09 

2008    /  /  08    .    .    08    .    .    08    .    .    08 

2007    /  /  07    .    .    07    .    .    07    .    .    07 

2006    /  /  06    .    .    06    .    .    06    .    .    06 

2005    /  /  05    .    .    05    .    .    05    .    .    05 

2004    /  /  04    .    .    04    .    .    04    .    .    04 

2003    /  /  03    .    .    03    .    .    03    .    .    03 

2002    /  /  02    .    .    02    .    .    02    .    .    02 

2001    /  /  01    .    .    01    .    .    01    .    .    01 

2000    /  /  00    .    .    00    .    .    00    .    .    00 


2009    /  /  09    .    .    09    .    .    09    .    .    09 

2008    /  /  08    .    .    08    .    .    08    .    .    08 

2007    /  /  07    .    .    07    .    .    07    .    .    07 

2006    /  /  06    .    .    06    .    .    06    .    .    06 

2005    /  /  05    .    .    05    .    .    05    .    .    05 

2004    /  /  04    .    .    04    .    .    04    .    .    04 

2003    /  /  03    .    .    03    .    .    03    .    .    03 

2002    /  /  02    .    .    02    .    .    02    .    .    02 

2001    /  /  01    .    .    01    .    .    01    .    .    01 

2000    /  /  00    .    .    00    .    .    00    .    .    00 


2009    /  /  09    .    .    09    .    .    09    .    .    09 

2008    /  /  08    .    .    08    .    .    08    .    .    08 

2007    /  /  07    .    .    07    .    .    07    .    .    07 

2006    /  /  06    .    .    06    .    .    06    .    .    06 

2005    /  /  05    .    .    05    .    .    05    .    .    05 


2009    /  /  09    .    .    09    .    .    09    .    .    09 

2008    /  /  08    .    .    08    .    .    08    .    .    08 

2007    /  /  07    .    .    07    .    .    07    .    .    07 

2006    /  /  06    .    .    06    .    .    06    .    .    06 

2005    /  /  05    .    .    05    .    .    05    .    .    05 


2009    /  /  09    .    .    09    .    .    09    .    .    09 

2008    /  /  08    .    .    08    .    .    08    .    .    08 

2007    /  /  07    .    .    07    .    .    07    .    .    07 

2006    /  /  06    .    .    06    .    .    06    .    .    06 

2005    /  /  05    .    .    05    .    .    05    .    .    05 


Only  fill  in  if  you  have  been  under  contract  for  these  time  periods. 


A.  B.  C.  D.  E. 

CLIENT  APPROX.  PERIOD  #  OF  PARKING  $  REVENUE  PAYMENTS 

OF  CONTRACTS  TICKETS  PROCESSED 

YR.  CY  FY  MO/YR  TO  MO/YR  ISSUED 
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1087O  FORM  #1 

*  5  LARGE  SCALE.  FULL  SERVICE  CLIENTS  FOR  PRIMARY  PARKING  TICKET  PROCESSING  THAT  ARE  MOST  SIMILAR  &  COMPARABLE  TO  BOSTON:  SUMMARY  DATA 


G.  H.  I.  J. 

#  MARKS  NON-RENEWALS  NOTICES  SEIZURES  VIOLATION 

FREQUENCY     #     CLEARS  FREQUENCY  #  NOTICES  FREQUENCY  TICKETS  PLATES  #  OF  BOOT      #  OF  TICKETS  TOWS 

MARKS  CLEARS  &  TOW  FOR  SEIZURE  # 

SEIZURES  ELIGIBILITY 


09   .  .      .  .     09  .  .         09   .    .   09 

08   .  .      .  .     08  .  .         08   .    .   08 

07   .  .      .  .     07  .  .         07   .    .   07 

06   .  .      .  .     06  .  .         06   .    .   06 

05   .  .      .  .     05  .  .         05   .    .   05 

04   .  .      .  .     04  .  .         04   .    .   04 

03   .  .      .  .     03  .  .         03   .    .   03 

02   .  .      .  .     02  .  .         02   .    .   02 

01   .  .      .  .     01  .  .         01   .    .   01 

00   .  .      .  .     00  .  .         00   .    .   00 


09   .  .      .  .     09  .  .         09   .    .   09 

08   .  .      .  .     08  .  .         08   .    .   08 

07   .  .      .  .     07  .  .         07   .    .   07 

06   .  .      .  .     06  .  .         06   .    .   06 

05   .  .      .  .     05  .  .         05   .    .   05 

04   .  .      .  .     04  .  .         04   .    .   04 

03   .  .      .  .     03  .  .         03   .    .   03 

02   .  .      .  .     02  .  .         02   .    .   02 

01   .  .      .  .     01  .  .         01   .    .   01 

00   .  .      .  .     00  .  .         00   .    .   00 


09   .  .      .  .     09  .  .         09   .    .   09 

08   .  .      .  .     08  .  .         08   .    .   08 

07   .  .      .  .     07  .  .         07   .    .   07 

06   .  .      .  .     06  .  .         06   .    .   06 

05   .  .      .  .     05  .  .         05   .    .   05 


09   .  .      .  .     09  .  .         09   .    .   09 

08   .  .      .  .     08  .  .         08   .    .   08 

07   .  .      .  .     07  .  .         07   .    .   07 

06   .  .      .  .     06  .  .         06   .    .   06 

05   .  .      .  .     05  .  .         05   .    .   05 


09   .  .      .  .     09  .  .         09   .    .   09 

08   .  .      .  .     08  .  .         08   .    .   08 

07   .  .      .  .     07  .  .         07   .    .   07 

06   .  .      .  .     06  .  .         06   .    .   06 

05   .  .      .  .     05  .  .         05   .    .   05 
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1098O  FORM  #3 

*  5  LARGE  SCALE.  FULL  SERVICE  CLIENTS  FOR  PRIMARY  PARKING  TICKET  PROCESSING  THAT  ARE  MOST  SIMILAR  &  COMPARABLE  TO  BOSTON:  SCOPE  OF  SERVICES  OVERVIEW 


A.  1.  2.  3.  4.  5.  6.  7. 

CLIENT  REQUIREMENTS  OF  CHANGES  TO  PARKING  TICKET  PARKING  UPDATING  TICKETS         LOCKBOX  ON-LINE,  REAL  TIME 

A  COMPREHENSIVE  &  SPEC'S  &  PICK-UP  RECEIPT  TICKET  DATA  TO  ON-LINE  &  POINT  OF  SALE  PAYMENT 

YR.  INTEGRATED  PVPMISS  REQUIREMENTS  AND  CONTROL  ENTRY/TRANSFER  MASTER  FILES  PROCESSING  SYSTEM 


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 

2004      04      04      04      04   04   04 

2003      03      03      03      03   03   03 

2002  02      02      02      02   02   02 

2001      01      01      01      01   01   01 

2000      00      00      00      00   00   00 


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 

2004  04      04      04      04   04   04 

2003      03      03      03      03   03   03 

2002  02      02      02      02   02   02 

2001      01      01      01      01   01   01 

2000      00      00      00      00   00   00 


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 


*  The  Scope  of  Services  Items  appearing  on  this  form  are  from  the  Scope  of  Services  Index,  Section  4.0.  The  items  on  this  form  have  the  same  #'s  as  they  do  in  Section  4.0. 
Refer  to  the  index  for  the  complete  wording  of  each  item. 
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1098O  FORM  #3 

*  5  LARGE  SCALE.  FULL  SERVICE  CLIENTS  FOR  PRIMARY  PARKING  TICKET  PROCESSING  THAT  ARE  MOST  SIMILAR  &  COMPARABLE  TO  BOSTON:  SCOPE  OF  SERVICES  OVERVIEW 


A.  8.  9.  10.  11.  12.  13.  14. 

CLIENT  REQUIRED  SCREEN  DATA  ONLINE/REAL  RMV  INTERFACE  DUNNING  BOOT  &  TOW  ABANDONED  MULTI-OWNER 

FOR  GENERAL  &  UNIV.  TIME  CLAIMS  SYSTEM  AND  NOTICES  VEHICLE  SYSTEM 

YR.  INQ.  &  CUSTOMER  SERV.  PROCESSING  SYS.  REQUIREMENTS  


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 

2004  04      04      04      04   04   04 

2003      03      03      03      03   03   03 

2002  02      02      02      02   02   02 

2001      01      01      01      01   01   01 

2000      00      00      00      00   00   00 


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 

2004  04      04      04      04   04   04 

2003      03      03      03      03   03   03 

2002  02      02      02      02   02   02 

2001      01      01      01      01   01   01 

2000      00      00      00      00   00   00 


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 


*  The  Scope  of  Services  Items  appearing  on  this  form  are  from  the  Scope  of  Services  Index,  Section  4.0.  The  items  on  this  form  have  the  same  #'s  as  they  do  in  Section  4.0. 
Refer  to  the  index  for  the  complete  wording  of  each  item. 
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1098O  FORM  #3 

*  5  LARGE  SCALE.  FULL  SERVICE  CLIENTS  FOR  PRIMARY  PARKING  TICKET  PROCESSING  THAT  ARE  MOST  SIMILAR  &  COMPARABLE  TO  BOSTON:  SCOPE  OF  SERVICES  OVERVIEW 


A.  15.  16.  17.  18.  19.  20.  21. 

CLIENT  METER  SIGN  VOICE  REFUND  MIS  PRODUCTION  NETWORK 

MANAGEMENT                               MANAGEMENT             RESPONSE                                                                                            SCHEDULE  CAPABILITY 
YR.  


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 

2004      04      04      04      04   04   04 

2003      03      03      03      03   03   03 

2002  02      02      02      02   02   02 

2001      01      01      01      01   01   01 

2000      00      00      00      00   00   00 


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 

2004  04      04      04      04   04   04 

2003      03      03      03      03   03   03 

2002  02      02      02      02   02   02 

2001      01      01      01      01   01   01 

2000      00      00      00      00   00   00 


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 


*  The  Scope  of  Services  Items  appearing  on  this  form  are  from  the  Scope  of  Services  Index,  Section  4.0.  The  items  on  this  form  have  the  same  #'s  as  they  do  in  Section  4.0. 
Refer  to  the  index  for  the  complete  wording  of  each  item. 
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1098O  FORM  #3 

*  5  LARGE  SCALE.  FULL  SERVICE  CLIENTS  FOR  PRIMARY  PARKING  TICKET  PROCESSING  THAT  ARE  MOST  SIMILAR  &  COMPARABLE  TO  BOSTON:  SCOPE  OF  SERVICES  OVERVIEW 


A.                          22.                                             23.                                24.                                       25.                                    26.                                   27.  28. 
CLIENT                     ON-LINE                             FILE  ARCHIVE                   RESIDENT  PERMIT              COMPLETE  SVS             DOCUMENTATION           PERFORMANCE  SECURITY 
AVAILABILITY                                                             PARKING  SYSTEM             TO  ALL  TICKETS             AND  USER  REPORT 
YR.  REQUIREMENTS  


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 

2004      04      04      04      04   04   04 

2003      03      03      03      03   03   03 

2002  02      02      02      02   02   02 

2001      01      01      01      01   01   01 

2000      00      00      00      00   00   00 


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 

2004  04      04      04      04   04   04 

2003      03      03      03      03   03   03 

2002  02      02      02      02   02   02 

2001      01      01      01      01   01   01 

2000      00      00      00      00   00   00 


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 


*  The  Scope  of  Services  Items  appearing  on  this  form  are  from  the  Scope  of  Services  Index,  Section  4.0.  The  items  on  this  form  have  the  same  #'s  as  they  do  in  Section  4.0. 
Refer  to  the  index  for  the  complete  wording  of  each  item. 
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1098O  FORM  #3 

*  5  LARGE  SCALE.  FULL  SERVICE  CLIENTS  FOR  PRIMARY  PARKING  TICKET  PROCESSING  THAT  ARE  MOST  SIMILAR  &  COMPARABLE  TO  BOSTON:  SCOPE  OF  SERVICES  OVERVIEW 


A.                              29.                                                30.                                 31.                                   32.                                 33.                                 34.  35. 
CLIENT                    BACK-UP  AND                             TRAINING                     CAPACITY  AND                 TEST  SYSTEM              REC.  FROM                 ORGANIZATION  SECONDARY 
ALT.  PROC.                                                                     VOLUMES                                                            CAT  FAIL.                        AND  COLLECTIONS 
YR.  PERSONNEL  


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 

2004      04      04      04      04   04   04 

2003      03      03      03      03   03   03 

2002  02      02      02      02   02   02 

2001      01      01      01      01   01   01 

2000      00      00      00      00   00   00 


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 

2004  04      04      04      04   04   04 

2003      03      03      03      03   03   03 

2002  02      02      02      02   02   02 

2001      01      01      01      01   01   01 

2000      00      00      00      00   00   00 


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 


*  The  Scope  of  Services  Items  appearing  on  this  form  are  from  the  Scope  of  Services  Index,  Section  4.0.  The  items  on  this  form  have  the  same  #'s  as  they  do  in  Section  4.0. 
Refer  to  the  index  for  the  complete  of  each  item. 
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1098O  FORM  #3 

*  5  LARGE  SCALE.  FULL  SERVICE  CLIENTS  FOR  PRIMARY  PARKING  TICKET  PROCESSING  THAT  ARE  MOST  SIMILAR  &  COMPARABLE  TO  BOSTON:  SCOPE  OF  SERVICES  OVERVIEW 


A.  36.  37.  38.  39.  40. 

CLIENT  CONVERSION  TICKET  WRITING  IMAGING  AND  TRAFFIC  MGMT.  RED  LIGHT  RUNNING 

DEVICE                         WORKFLOW              PERMITTING  SYSTEM        VIOLATION  ISSUANCE 
 YR.  PROGRAM  


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 

2004  04      04      04      04   04   04 

2003      03      03      03      03   03   03 

2002  02      02      02      02   02   02 

2001      01      01      01      01   01   01 

2000      00      00      00      00   00   00 


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 

2004  04      04      04      04   04   04 

2003      03      03      03      03   03   03 

2002  02      02      02      02   02   02 

2001      01      01      01      01   01   01 

2000      00      00      00      00   00   00 


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006      06      06      06      06   06   06 

2005      05      05      05      05   05   05 


2009      09      09 

2008      08      08 

2007      07      07 

2006      06      06 

2005      05      05 


*  The  Scope  of  Services  Items  appearing  on  this  form  are  from  the  Scope  of  Services  Index,  Section  4.0. 
Refer  to  the  index  for  the  complete  wording  of  each  item. 


09      09   09   09 

08      08   08   08 

07      07   07   07 

06      06   06   06 

05      05   05   05 


The  items  on  this  form  have  the  same  #'s  as  they  do  in  Section  4.0. 
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FORM  #2:    Additional  10  PVPMISS  Clients  For  Primary  Ticket  Processing 


Instructions  for  Completion: 
(page  1  of  1  of  instructions) 


List  up  to  10  other  clients  that  did  not  appear  on  CLIENT  FORM  #1.  List  the  clients, 
1  - 10,  in  order  of  their  similarity  and  comparability  to  Boston.  (The  client  listed  as 
number  T  would  be  considered  the  most  similar  and  comparable  and  the  client  listed  as 
number  '10'  would  be  considered  the  least  similar  and  comparable.) 


Column  A:  Indicate  additional  Clients  that  are  most  similar  and  comparable  to  Boston 
in  terms  of  the  number  of  parking  tickets  and  the  RFP  PVPMISS  requirements  relative 
to  number,  size,  scope,  and  level  of  integration  and  complexity  of  the  systems  and 
services. 


Column  B:  Provide  data  on  the  clients  for  the  past  5  years.  Indicate  with  an  "X"  if  the 
data  is  for  a  calendar  year  or  a  fiscal  year.  Also,  indicate  the  months  that  you  provided 
systems  and  services  under  contract  to  the  Client.  Examples:  2000:  cy  /fy  X.  7/99  to 
6/00;  2000:  cy_/fyX  7/99  to  12/99;  cy_JC/fy_,  1/00  to  8/00.  For  2000,  whether 
calendar  or  fiscal  year,  if  you  are  continuing  to  provide  service  beyond  the  month 
indicated,  please  put  an  asterisk  next  to  the  year  (e.g.  6/00*). 


Column  C:  Indicate  the  number  of  parking  tickets  issued.  (Do  not  include  moving 
violations  or  other  types  of  violations) 


Column  D:  Indicate  the  revenue  from  parking  tickets  fines  and  penalties.  (Do  not 
include  revenue  from  other  sources  such  as  but  not  limited  to  moving  violations,  seizure 
fees,  tow  fees,  meter  revenue,  and  storage  fees.) 
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1091o  FORM  #2 


A. 

CLIENT 


B. 

APPROX.  PERIOD 
OF  CONTRACTS 
MO/YR  TO  MO/YR 


ADDITIONAL  10  PVPMISS  CLIENTS  FOR  PRIMARY  PARKING  TICKET  PROCESSING 
C.  D.  A. 

#  OF  PARKING         $  REVENUE  CLIENT 
TICKETS 

ISSUED    YJL  CY  FY 


B. 

APPROX.  PERIOD 
OF  CONTRACTS 
MO/YR  TO  MO/YR 


C. 

#  OF  PARKING 
TICKETS 
ISSUED  


D. 

$  REVENUE 


2009 

/ 

/  09 

09 

2008 

/ 

/  08 

08 

2007 

/ 

/  07 

07 

2006 

/ 

/  06 

06 

2005 

/ 

/  05 

05 

2009 

/ 

/  09 

09 

2008 

/ 

/  08 

08 

2007 

/ 

/  07 

07 

2006 

/ 

/  06 

06 

2005 

/ 

/  05 

05 

2009 

/ 

/ 

09 

09 

2008 

/ 

/ 

08 

08 

2007 

/ 

/ 

07 

07 

2006 

/ 

/ 

06 

06 

2005 

/ 

/ 

05 

05 

2009 

/ 

/ 

09 

09 

2008 

/ 

/ 

08 

08 

2007 

/ 

/ 

07 

07 

2006 

/ 

/ 

06 

06 

2005 

/ 

/ 

05 

05 

3.   8. 


2009 

/ 

/  09 

09 

2009 

/ 

/  09 

09 

2008 

/ 

/  08 

08 

2008 

/ 

/  08 

08 

2007 

/ 

/  07 

07 

2007 

/ 

/  07 

07 

2006 

/ 

/  06 

06 

2006 

/ 

/  06 

06 

2005 

/ 

/  05 

05 

2005 

/ 

/  05 

05 

4.   9. 


2009 

/ 

/  09 

09 

2009 

/ 

/  09 

09 

2008 

/ 

/  08 

08 

2008 

/ 

/  08 

08 

2007 

/ 

/  07 

07 

2007 

/ 

/  07 

07 

2006 

/ 

/  06 

06 

2006 

/ 

/  06 

06 

2005 

/ 

/  05 

05 

2005 

/ 

/  05 

05 

2009 

/ 

/ 

09 

09 

2008 

/ 

/ 

08 

08 

2007 

/ 

/ 

07 

07 

2006 

/ 

/ 

06 

06 

2005 

/ 

/ 

05 

05 

10._ 


2009 

/ 

/ 

09 

09 

2008 

/ 

/ 

08 

08 

2007 

/ 

/ 

07 

07 

2006 

/ 

/ 

06 

06 

2005 

/ 

/ 

05 

05 

Only  fill  in  if  you  have  been  under  contract  for  these  time  periods. 

OTHER  PARKING  TICKET  CLIENTS  (Indicate  name  of  client,  annual  issuance,  and  contract  periods,  for  ex.  Miami  600,000  4/90  -  12/95):  Use  separate  sheet  if  needed. 
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FORM  #  4 

PROPOSER  PVPMISS  EXPERIENCE  FORM 


Use  one  form  per  client,  for  a  maximum  of  five  clients  that  appear  on  Form  #1  or  Form 
#2.  Select  experience  for  systems  which  are  most  similar  and  comparable  to  the  City  of 
Boston's  PVPMISS  and  which  have  been  in  operation  for  the  most  number  of  years. 

Client  Organization  Name: 


Duration  of  Involvement: 
From:   To: 


Conversion  Phase: 
From:  


To: 


Operational  Phase: 
From:   To: 


Type  of  Business: 


Contact  Person  and  Title: 


Address  and  Telephone  Number: 


Project  System  Profile: 

1.        Number  of  parking  violations/year  in  most  recent  two  fiscal  or  calendar  years: 


2.  Gross  parking  violation  collection/year  in  most  recent  two  fiscal  or  calendar 
years: 


Explain  why  we  should  consider  this  reference  a  viable  PVPMISS  reference.  In  light  of 
our  RFP,  relate  the  functionality,  components,  capabilities,  benefits,  features,  etc.,  of  this 
experience  to  the  elements  of  our  RFP.  Describe  in  as  much  detail  as  possible  so  that  we 
can  assess  the  relevancy  of  this  experience  to  our  RFP.  Please  note  various  processing 
volumes  for  elements,  components,  services,  etc.  if  they  have  not  been  provided  on  one 
of  the  other  forms. 

Note:  Additional  pages  may  be  attached  for  each  Proposer  PVPMISS  Experience  Form 
if  needed  to  fully  describe  the  experience,  explain  the  reference  as  a  viable  PVPMISS 
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reference  and  its  relevancy  to  our  RFP.  No  or  limited  credit  will  be  given  for  responses 
using  other  formats  or  for  experience  which  cannot  be  verified  by  the  reference  given. 
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FORM  #  5 

(Page  1  of  6) 

PVPMISS  EMPLOYEE  BACKGROUND  FORM 


This  form  is  intended  to  identify  vendor  employee  backgrounds  as  they  directly  relate  to 
PVPMISS  experience.  This  form  should  be  used  to  provide  employee  backgrounds  for 
key  :  a)  conversion  staff;  b)  post  conversion  staff;  and  c)  on-call  staff.  Conversion  staff 
are  those  employees  who  would  plan  and  execute  the  system  conversion  that  would  be 
required  if  the  Selected  Vendor  is  not  the  Existing  Vendor.  Post-conversion  staff  are 
those  employees  responsible  for  the  system's  ongoing  operation,  maintenance, 
alterations,  development,  enhancement,  etc.  On-call  staff  are  those  employees 
unassigned  to  ongoing  operational  or  developmental  responsibilities  who  would  be 
available  resources  for  assistance  as  the  need  arises.  Resume's  of  these  key  personnel 
should  also  be  provided. 

Proposer's  Name:  Employee's  Name  and  Title: 


Employee's  years  of  experience  with:  a)  Parking  Violation  Systems 


b)  Related  Systems: 


Employee's  staff  categorization  for  the  Boston  PVPMISS  (mark  appropriate  categories) 
and  identify  the  normal  worksite/location  of  the  employee: 

a)  Conversion   b)  Post-conversion   c)  On-call  

Worksite   Worksite   Worksite  


Description  of  planned  role  in  the  Boston  PVPMISS: 

Percentage  of  employee's  time  to  be  devoted  to  the  Boston  PVPMISS  (for  on-call  staff 
enter  the  maximum  percentage  availability): 

a)  Conversion  %    b)  Post-conversion  %        c)  On-call  % 

Worksite   Worksite   Worksite  


Identify  on  the  following  pages,  for  one  to  a  maximum  of  five  (5)  systems  that  are/were 
most  similar  to  Boston's  PVPMISS  that  provided  the  employee  with  PVPMISS 
experience.  No  or  limited  credit  will  be  given  for  incomplete  responses,  responses  using 
other  formats,  or  for  systems  which  cannot  be  verified  by  the  references  given.  Two 
additional  pages  may  be  attached  for  each  of  the  five  systems  if  needed  to  fully  describe 
the  employee's  role  and  responsibilities. 
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Note:  If  you  believe  that  experience  from  five  (5)  systems  does  not  adequately  indicate  an 
employee's  experience,  you  may  submit  an  additional  one  page  summary. 
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FORM  #5  (page  2  of  6) 
System  Name  : 

Employer's  Name  if  not  Proposer: 


Duration  of  Involvement: 
from:   to:  


Client  Organization's  Name: 


Employer  Reference:  Client  Reference: 

Name:   Name:  

Telephone  :   Telephone:  


Describe  the  system  and  the  employee's  role  in  the  system.  We  are  most  interested  in  the 
relationship  between  the  employee's  experience  and  the  systems  and  elements  in  our 
RFP. 
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System  Name: 


Employer's  Name  if  not  Proposer: 


FORM  #5  Tpage3of6) 

Duration  of  Involvement: 
from:   to:  


Client  Organization's  Name: 


Employer  Reference:  Client  Reference: 

Name:   Name:  

Telephone  :   Telephone:  


Describe  the  system  and  the  employee's  role  in  the  system.  We  are  most  interested  in  the 
relationship  between  the  employee's  experience  and  the  systems  and  elements  in  our 
RFP. 
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System  Name: 


Employer's  Name  if  not  Proposer: 


FORM  #5  Tpage4of6) 

Duration  of  Involvement: 
from:   to:  


Client  Organization's  Name: 


Employer  Reference:  Client  Reference: 

Name:   Name:  

Telephone:   Telephone:  


Describe  the  system  and  the  employee's  role  in  the  system.  We  are  most  interested  in  the 
relationship  between  the  employee's  experience  and  the  systems  and  elements  in  our 
RFP. 
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System  Name: 


Employer's  Name  if  not  Proposer: 


FORM  #5  Tpage5of6) 


Duration  of  Involvement: 
from:   to: 


Client  Organization's  Name: 


Employer  Reference:  Client  Reference: 

Name:   Name:  

Telephone:   Telephone:  


Describe  the  system  and  the  employee's  role  in  the  system.  We  are  most  interested  in  the 
relationship  between  the  employee's  experience  and  the  systems  and  elements  in  our 
RFP. 
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System  Name: 


FORM  #  5  fpage  6  of  6) 
Duration  of  Involvement: 


Employer's  Name  if  not  Proposer:  Client  Organization's  Name: 


Employer  Reference:  Client  Reference: 
Name:   Name:  


Telephone:   Telephone: 


Describe  the  system  and  the  employee's  role  in  the  system.  We  are  most  interested  in  the 
relationship  between  the  employee's  experience  and  the  systems  and  elements  in  our 
RFP. 
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FORM  #  6 

(Page  1  of  6) 

MOTOR  VEHICLE  AGENCY  INTERFACE  EXPERIENCE  FORM 


Use  this  form  to  describe  capabilities  and  features  utilized,  experience  gained,  and 
effectiveness  demonstrated  with  Motor  Vehicle  Agency  interfaces  within  the  last  five  (5) 
years.  Fully  describe  the  capabilities,  features,  experience  and  demonstrated 
effectiveness. 

Instructions: 

On  a  separate  page(s)  in  matrix  form,  marked  Form  #  6  Matrix  Attachment, 
provide  the  following  information.  For  each  Motor  Vehicle  Agency  with  which 
you  have  interfaced  to  retrieve  and  process  registrant  data,  provide  volumes, 
frequencies  and  hit  rates  for  the  following:  Registrant  Identification  Information 
(name  and  address,  etc.,  requests),  and  Non-Renewal  Marks  and  Clears.  Data 
should  be  for  each  of  the  last  five  (5)  years  in  twelve  (12)  month  calendar  or 
fiscal  year  increments  to  the  extent  possible.  The  specific  cities  /  entities 
requiring  the  Motor  Vehicle  Agency  interface  should  be  indicated  for  each  agency 
experience  cited. 

I.        Registrant  /  Registration  Data 

1.        Describe  your  motor  vehicle  agency  interface  to  retrieve  registrant  data  in  detail: 
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FORM  #  6  fpage  2  of  6) 

Describe  and  substantiate  your  success  rate  achieved  for  obtaining  registrant  data 
and  enumerate  the  reason  why  registrant  information  is  not  secured: 


Describe  in  detail  your  procedures  to  edit  and  utilize  registrant  data  provided: 


Describe  what  happens  to  registration  records  when  no  data  is  returned  from 
motor  vehicle  agency: 
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FORM  #  6  fpage  3  of  6) 


II.       Non-Renewal  Processing 

1.        Describe  your  experience  and  capability  to  interface  and  process  non-renewal  of 
license  /  registration  mark  and  clear  transactions  to  motor  vehicle  agencies.  List 
the  specific  motor  vehicle  agencies  with  which  you  have  interfaced,  the  specific 
cities  /  entities  requiring  this  interface,  the  time  frames  of  involvement  and  the 
volume  and  frequency  of  transactions: 


2.        Describe  how  you  generate,  edit  and  utilize  registrant  information  for  non- 
renewal interface: 
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FORM  #  6  fpage  4  of  6) 


Describe  and  substantiate  your  success  rate  for  facilitating  non-renewal 
transactions: 


Describe  what  happens  to  registration  records  that  are  not  successfully 
'non-renewed'  during  initial  non-renewal  attempts: 
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FORM  #  6  fpage  5  of  6) 


III.      Linkage  of  Plates  to  Registrants 

1.        Describe  your  experience  and  capability  to  link  expired  registrations  with  the 
same  registrants'  current  registrations.  List  the  motor  vehicle  agencies  with 
which  you  have  interfaced,  the  specific  cities  /  entities  requiring  this  interface,  the 
volume  of  transactions  and  the  time-frame  of  involvement.  Also,  describe  the 
logic  utilized  to  link  past  with  present  registrations: 
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FORM  #  6  fpage  6  of  6) 

IV.      Identification  and  Noticing  of  Registrants  /  Registrations 

Describe  your  experience  /  capability  to  maximize  the  identification  and  noticing  of  the 
correct  registrant  and  minimize  the  misidentification  and  noticing  of  the  incorrect 
registrant  by: 

A.  Methods  and  approaches  utilized  to  request  registrant  /  registration  data. 

B.  Methods  and  approaches  utilized  to  process  and  update  registration  data  from 
motor  vehicle  agencies. 
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FORM  #  7 

(page  1  of  2) 

PVPMISS  PROPOSER  OVERVIEW  FORM 


I.        General  Information:  On  a  separate  sheet(s),  marked  Form  #7.  provide  the 

following  information  in  a  clear  manner.  If  multiple  pages  are  submitted,  please 
consecutively  number  all  pages  for  this  response  (e.g.,  'Form  #7,  Page  lof  X'). 

Note  to  Proposers:  Completion  of  this  form  does  not  relieve  proposers  from 
responding  to  other  sections  of  the  RFP  (e.g.,  Section  4.34,  "Organization,  Plan  of 
Services  and  Personnel"). 

A.  Name  of  Primary  Proposer 

B.  Address  of  central  office/headquarters 

C.  Address  of  office  that  will  be  responsible  for  this  contract  (if  different 
from  above  address) 

D.  Address  of  computer/data  centers  that  will  be  responsible  for  providing  service 
under  a  Boston  PVPMISS  contract 

E.  Address  of  regional/field  office  that  will  be  responsible  for  providing  service 
under  a  Boston  PVPMISS  contract 

F.  Address  of  local/field  office  (if  available)  that  will  be  responsible  for  providing 
service  under  a  Boston  PVPMISS  contract 


II.       Organization  (Plan  of  Services  and  Personnel) 

A.  For  the  full  potential  operational  period  of  the  contract,  including  renewal 

options  (July  1,  2007  -  June  30,  2010),  assuming,  full  operation  of  all  July  1,  2007  required 
systems  and  services,  provide  on  one  or  more  separate  sheets: 

1.  A  description/presentation  via  chart,  matrix,  table  or  other  format  and 
a  narrative,  if  desired,  of  your  'company- wide'  PVPMISS 
organization.  As  part  of  your  presentation,  include  positions,  titles 
and  number  of  employees  in  each  position  and  a  brief  description  of 
roles,  duties  and  responsibilities  for  each  title.  The  numbers,  types, 
locations  of  staff  and  offices  for  all  types  of  functions  and  activities 
should  be  clearly  discernable. 
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Form  #  7  (page  2  of  2) 


2.  Indicate  the  parts  of  the  organization  and  plan  of  services  that  will  be 
dedicated  to  the  Boston  PVPMISS.  Again,  you  may  provide  this 
information  through  a  description/presentation  via  chart,  matrix,  table 
or  other  format  and  a  narrative,  if  desired,  of  your  Boston  PVPMISS 
organization  and  plan  of  services.  As  part  of  your  presentation, 
include  positions,  titles  and  number  of  employees  in  each  position  and 
a  brief  description  of  roles,  duties  and  responsibilities  for  each  title. 
This  includes,  but  is  not  limited  to,  internal  Proposer  operations, 
personnel  and  facilities;  and  external  operations,  activities  and 
relationships  (i.e.,  with  Motor  Vehicle  Departments,  various  BTD 
divisions,  City's  Voice  Response  Hardware  company,  various 
subcontractors,  if  applicable).  The  numbers,  types  and  locations  of 
staff  and  offices  for  all  types  of  functions  and  activities  should  be 
clearly  discernable. 

B.  For  the  conversion  period  (the  period  of  time  up  until  PVPMISS  is  fully 
operational  with  all  components  and  systems),  on  one  or  more  separate 
sheets,  indicate  the  parts  of  the  organization/organizational  structure  that 
will  be  dedicated  to  the  Boston  PVPMISS.  You  can  provide  this 
information  through  a  description/presentation  via  chart,  matrix,  table  or 
other  format  and  a  narrative,  if  desired,  of  your  Boston  PVPMISS 
organization/organizational  structure.  As  part  of  your  presentation,  include 
positions/titles,  number  of  employees  in  each  position  and  a  brief 
description  of  roles,  duties  and  responsibilities  for  each  title. 

C.  For  each  different  location,  such  as  central  office,  data  center  regional 
office,  local  office,  etc.,  provide  a  listing  and  numbers  of  staff  in  each 
position/title,  a  further  breakdown  by  percentage  of  time  the  actual 
employees  filling  the  positions/titles  will  be  assigned  to  the  Boston 
PVPMISS  and  preferably,  the  names  of  the  employees  in  the 
positions/titles.  (Note:  for  example,  if  there  are  three  employees  in  a 
particular  position  and  they  will  be  assigned  to  the  Boston  PVPMISS  for 
different  percentages  of  time,  then  indicate  the  percentage  of  time  that  each 
will  be  assigned  to  the  Boston  PVPMISS.) 
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FORM  #  8 


PVPMISS  PERSONNEL  MATRIX 

Instructions:  At  a  minimum,  list  all  key  personnel  that  will  be  assigned  to  the  Boston  PVPMISS 

and  fill  in  each  column  as  indicated  by  the  column  heading.  If  multiple  pages  are  submitted,  please 


consecutively  number  all  pages  for  this  response  (e.g.,  'Form  #8,  Page  lof  X'). 


Proposer  Staff 

%  of  Time 
Assigned 
to  Boston 

Available 
Resource 

"\/  /TVT 

Y/JN 

Project 
Review 

Y/JN 

Parking 
Management 
Prog.  Expr. 
(Years) 

Parking 
Operations 
Experience 
(Years) 

Parking 
Systems 
Tech.  Expr. 
(Years) 

Technical 
Experience 
(Years) 

Business 
Experience 
(Years) 

Company 
Experience 
(Years) 
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FORM  #  8A 


PVPMISS  PERSONNEL  MATRIX 
HAND  HELD  TICKET  WRITING  DEVICES 


Instructions:  At  a  minimum,  list  all  key  personnel  that  will  be  assigned  to  the  Boston  PVPMISS  HHD  program  for  implementation 
and  maintenance  and  fill  in  each  column  as  indicated  by  the  column  heading.  If  multiple  pages  are  submitted,  please  consecutively 


number  all 

Dages  for  t 

lis  response  (e.g.,  'Form  #8A,  Page  lof  X'). 

Proposer  Staff 

%  of  Time 
Assigned 
to  Boston 

Available 
Resource 
Y/N 

Project 
Review 
Y/N 

On-Site  for 
Installation 

Y/N 

On-Site  for 
Training 
Y/N 

Parking 
Operations 
Experience 
(Years) 

Parking 
Systems 
Tech.  Expr. 
(Years) 

hlanu-hlela 
Technical 
Experience 
(Years) 

Company 
Experience 
(Years) 
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FORM  #  9 

DATA  CENTER  HARDWARE  AND  TECHNICAL  ENVIRONMENT 


On  a  separate  sheet  (s),  marked  Form  #  9,  provide  the  following  information  in  a  clear 
manner: 

I.  Identify  your  PVPMISS  Data  Center  hardware  and  technical  environment. 

II.  Fully  discuss  hardware  capability,  ability  to  meet  time  frame  and  Scope  of 
Services  scheduling  requirements  and  ability  to  efficiently  and  effectively  process 
estimated  volumes  indicated. 

III.  Fully  discuss  hardware  expandability,  ability  to  handle  surges  in  volumes  and 
demand  for  computer  processing  time,  and  ability  to  handle  multiple  simultaneous 
projects. 

IV.  Fully  discuss  ability  to  comply  with  Scope  of  Services  scheduling  and  processing 
requirements  in  light  of  other  client  demands  and  overall  competition  for 
computing  time. 

V.  Indicate  all  control,  support  and  utility  software  with  appropriate  release  levels 
required. 

VI.  Fully  discuss  network  capability,  ability  to  meet  timeframe  Scope  of  Services 
requirements  and  ability  to  efficiently  and  effectively  process  estimated  volumes 
indicated. 

VII.  Fully  discuss  network  expandability  and  upgradability,  ability  to  handle  surges  in 
volumes  and  demand  for  computer  processing  time,  and  ability  to  handle  multiple 
simultaneous  projects. 

VIII.  Indicate  all  LAN/WAN  support  and  software  with  appropriate  release  levels 
required. 

Note:  Proposers  may  include  pictorial  illustrations,  graphs,  matrixes,  charts  or  tables  in 
addition  to  narrative  descriptions.  If  multiple  pages  are  submitted,  please  consecutively 
number  all  pages  for  this  response  (e.g.,  'Form  #  9,  page  lof  X). 
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INSTRUCTIONS  FOR  FORM  #  10 


The  following  form  should  be  completed  for  5  large  scale  full  service  clients  for  Hand- 
Held  Ticket  Writing  Devices  that  are  most  similar  and  comparable  to  City  of  Boston 
requirements.  Scope  of  Services  4.37. 

The  City  in  a  similar  manner  to  other  major  cities  in  this  and  other  countries  requires  and 
mandates  that  the  HHD's  be  ruggedized,  fully  tested,  debugged,  proven  in  major  urban 
city  production  environments,  and  determined  to  be  completely  reliable  for  the  basic, 
repetitive  task  of  entering  standard  information  and  generating  a  parking  ticket.  Further, 
due  to  the  large  number  of  potential  users  with  varying  backgrounds  relative  to  computer 
usage,  the  HHD  should  be  designed  to  require  an  extremely  minimal  degree  of  technical 
dexterity  for  operation.  Additionally,  for  labor  force  and  various  operational  reasons 
including,  but  not  limited  to,  weather  and  clothing,  the  City  is  requires  and  mandates  a 
combined,  one  (1)  piece  design  for  the  issuing  device  and  the  printing  device.  The 
selected  vendor  will  also  be  required  to  have  a  well-established,  reputation  that  can  be 
substantiated  and  documented  as  a  subject-matter  experienced  vendor  in  providing 
proven  HHD's  for  on-street  parking  solutions  with  extensive  and  specialized  experience, 
knowledge,  abilities  and  skills  for  parking  ticket  issuance  enforcement  and  parking 
management  applications  in  large  urban  environments.  Moreover,  the  selection  of  a 
vendor  will  also  be  subject  to  the  vendor's  ability  to  substantiate  and  document  its 
capabilities  to  provide  a  reliable  and  ready  to  use,  at  the  start  of  the  contract,  turnkey 
HHD  system  (with  proven  products,  systems  and  services).  Additionally,  as  part  of  RFP 
submission,  the  vendor  must  clearly  demonstrate  and  substantiate  its  hardware,  software, 
existing  specifications,  and  related  equipment  and  service  ability  and  capabilities  to  avoid 
a  development  process  during  the  initial  deployment  of  the  HHD. 

Again,  the  following  form  should  be  completed  for  5  large  scale  full  service  clients  for 
Hand-Held  Ticket  Writing  Devices  that  are  most  similar  and  comparable  to  City  of 
Boston  requirements.  For  each  client,  please  complete  Form  #  10  for  up  to  three  (3) 
different  brands  of  HHD's. 


335 


FORM  #10 

*  5  LARGE  SCALE.  FULL  SERVICE  CLIENTS  FOR  HAND-HELD  TICKET  WRITING  DEVICES  THAT  ARE  MOST  SIMILAR  &  COMPARABLE  TO  BOSTON  REQUIREMENTS:  SCOPE  OF  SERVICES 

(437) 


A.                               1.                                                 2.                                     3.                                4.                                  5.                                    6.  7. 
CLIENT                 REQUIREMENTS  OF                        EQUIPMENT                  REPAIRS  &  REPLACING     TRANSMISSION         BATTERIES                   INTERFACE                   DATA  EXPORT 
THE  VENDOR                                  REQUIREMENTS            HHDs  &  SUPPORTING        CRADLES/DEVICES                                       CAPABILITIES               AND  IMPORT 
YR.  PROVISION  OF  HHDs  EQUIPMENT  &  CHARGERS  


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 

2004      04      04      04      04   04   04 

2003      03      03      03      03   03   03 

2002  02      02      02      02   02   02 

2001      01      01      01      01   01   01 

2000      00      00      00      00   00   00 


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006      06      06      06      06   06   06 

2005      05      05      05      05   05   05 

2004  04      04      04      04   04   04 

2003      03      03      03      03   03   03 

2002  02      02      02      02   02   02 

2001      01      01      01      01   01   01 

2000      00      00      00      00   00   00 


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006      06      06      06      06   06   06 

2005      05      05      05      05   05   05 


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 


*  The  Scope  of  Services  Items  appearing  on  this  form  are  from  the  Scope  of  Services  Section  4.37.  Refer  to  this  section  for  the  complete  wording  of  each  item. 
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FORM  #10 

*  5  LARGE  SCALE.  FULL  SERVICE  CLIENTS  FOR  HAND-HELD  TICKET  WRITING  DEVICES  THAT  ARE  MOST  SIMILAR  &  COMPARABLE  TO  BOSTON  REQUIREMENTS:  SCOPE  OF  SERVICES 

(4-37) 


A.                                   8.                                             9.                                 10.                                   11.                                12.                                  13.  14. 
CLIENT                 DEVELOPMENT  OF                          SPECIFIED  &                 SECURITY                     CAPTURED  TICKET       CAPABILITIES  FOR        **  OTHER  MAINTENANCE 
ADDITIONAL  APPS.                         AD  HOC  REPORTS                                             INFORMATION              TURNKEY  SYSTEM        REQUIREMENTS  CONTRACT 
YR.  &  ENHANCEMENTS  


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006      06      06      06      06   06   06 

2005      05      05      05      05   05   05 

2004  04      04      04      04   04   04 

2003      03      03      03      03   03   03 

2002  02      02      02      02   02   02 

2001      01      01      01      01   01   01 

2000      00      00      00      00   00   00 


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 

2004      04      04      04      04   04   04 

2003      03      03      03      03   03   03 

2002  02      02      02      02   02   02 

2001      01      01      01      01   01   01 

2000      00      00      00      00   00   00 


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006  06      06      06      06   06   06 

2005      05      05      05      05   05   05 


2009      09      09      09      09   09   09 

2008      08      08      08      08   08   08 

2007      07      07      07      07   07   07 

2006      06      06      06      06   06   06 

2005      05      05      05      05   05   05 


*  The  Scope  of  Services  Items  appearing  on  this  form  are  from  the  Scope  of  Services  Section  4.37.  Refer  to  this  section  for  the  complete  wording  of  each  item. 

**This  section  refers  to  Software,  Physical/Environmental  Characteristics,  Processor  &  Memory,  Operating  System,  Keyboard/Screen,  Printer,  Ticket  &  Printer  Supplies  and  Training. 
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FORM  #10 

*  5  LARGE  SCALE.  FULL  SERVICE  CLIENTS  FOR  HAND-HELD  TICKET  WRITING  DEVICES  THAT  ARE  MOST  SIMILAR  &  COMPARABLE  TO  BOSTON  REQUIREMENTS:  SCOPE  OF  SERVICES 

(4-37) 

A.  15.  16.  17.  18. 

CLIENT  WARRANTY  DOCUMENTATION  TECH.  SUPPORT  TOW  LOT  FACILITY 

&  DEVELOPMENT 


2009      09      09      09 

2008      08      08      08 

2007      07      07      07 

2006  06      06      06 

2005      05      05      05 

2004      04      04      04 

2003      03      03      03 

2002  02      02      02 

2001      01      01      01 

2000      00      00      00 


2009      09      09      09 

2008      08      08      08 

2007      07      07      07 

2006      06      06      06 

2005      05      05      05 

2004  04      04      04 

2003      03      03      03 

2002  02      02      02 

2001      01      01      01 

2000      00      00      00 


2009      09      09      09 

2008      08      08      08 

2007      07      07      07 

2006  06      06      06 

2005      05      05      05 


2009      09      09      09 

2008      08      08      08 

2007      07      07      07 

2006      06      06      06 

2005      05      05      05 


2009      09      09      09 

2008      08      08      08 

2007      07      07      07 

2006  06      06      06 

2005      05      05      05 


*  The  Scope  of  Services  Items  appearing  on  this  form  are  from  the  Scope  of  Services  Section  4.37.  Refer  to  this  section  for  the  complete  wording  of  each  item. 
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